Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:9V != 18W (Score 2, Funny) 366

Teenager Invents Cheap Solar Panel From Human Hair

This is nothing. I once created the Ultimate Pleasure Device from 2 bottles of cheap wine, 10 ounces of ground beef (lean) and and a 12" piece of PVC tubing.

THIS is nothing. Once I created a railway rifle with nothing more than a crutch, fission battery, pressure cooker and a steam gauge assembly.

Comment Re:Eh. (Score 1) 140

And, IMO, the story takes a negative turn near the end. I don't think it's a coincidence. Although a story CAN be good regardless of the battle system, I think the battle system has a huge effect on your impression of the characters. After all, you spend most of your time with these characters in battle, not in cut scenes. They shouldn't be replaceable cogs.

This is why I consider Final Fantasy 4 to be the best in the series and Final Fantasy 7 to be near the bottom. 7 gave me the choice to never use Aeris. Unfortunately, I made that choice (it was pretty arbitrary; everyone is a replaceable cog in that game, after all). As a result, when she died, I didn't care much. It was like a random NPC in a town died. If she was a key part of my team, I think I would have felt different.

Comment Re:Nonsequitor in the summary (Score 1) 455

Likewise giving fan made games like this a nod cheapens the brand.

Does turning a blind eye to the fan made games cheapen the brand?

On another note, I don't know much about Japanese culture but isn't making fan fiction knockoffs of things practically legal over there? I hear that Dojinshi (fan fiction comic books based on copyrighted characters) is so ubiquitous, there are actually large conventions for them [citation].

Comment Re:From a developer's perspective (Score 1) 99

3) They have a hiring problem. If a company is forcing their employees to do 16 hour days they really are trying to do all the work with half the people they need.

It doesn't work that way. I suggest you read the Mythical Man Month.

That being said, I think they most likely do have a hiring problem. How the hell are you supposed to sharpen your saw when you work 80 hour weeks?

Is the quality of a game and the morale of the team worth sacrificing to deliver the product on its arbitrarily chosen completion date?

Comment Re:There you go again! (Score 4, Informative) 324

Jane Q. Public: Either you didn't read the comments of that blog or you're spreading FUD. Here is a comment from Alex Payne from that article:

Hoo boy. First of all, I hope you've had a chance to read my general reply to the articles about my Web 2.0 Expo talk [1] and this response to a vocal member of the Ruby community [2]. I sound like a pretty unreasonable guy filtered through the tech press and Reddit comments, but I hope less so in my own words.

Secondly, the quote at the top of your post is from my coworker, Steve Jenson, who's been participating in the discussion on this post.

On JRuby: as Steve said, we can't actually boot our main Rails app on JRuby. That's a blocker. Incidentally, if you know of anyone who has a large JRuby deployment, we'd be interested in that first-hand experience. If you don't, it might be a little early to say it would solve all our problems.

It's also incorrect to say that the way JRuby and Scala make use of the JVM is exactly the same. Much like our other decisions haven't been arbitrary, our decision to use Scala over other JVM-hosted languages was based on investigation.

On our culture: if you'd like to know about how we write code, or how our code has evolved over time, just ask us. We're all on Twitter, of course, but most of the engineers also have blogs and publish their email addresses. There's no need to speculate. Just ask. There's not a "raging debate" internally because we make our engineering decisions like engineers: we experiment, and base our decisions on the results of those experiments.

It's definitely true that Starling and Evented Starling are relatively immature queuing systems. I was eager to get them out of our stack. So, as Steve said, we put all the MQ's you think we'd try through their paces not too long ago, and we knocked one after another over in straightforward benchmarks. Some, like RabbitMQ, just up and died. Others chugged on, but slowly. Where we ran into issues, we contacted experts and applied best practices, but in the end, we found that Kestrel fit our particular use cases better and more reliably. This was not the hypothesis we had going into those benchmarks, but it's what the data bore out.

We get a lot of speculation to the tune of "why haven't those idiots tried x, it's so obvious!" Generally, we have tried x, as well as y and z. Funnily enough, I was actually pushing to get us on RabbitMQ, but our benchmarks showed that it just wouldn't work for us, which is a shame, because it advertises some sexy features.

Personally, I'm extremely NIH-averse; I research open source and commercial solutions before cutting a new path. In the case of our MQ, one of our engineers actually wrote Kestrel in his free time, so it was bit more like we adopted an existing open source project than rolled our own. Pretty much the last thing we want to be doing is focusing on problems outside our domain. As it so happens, though, moving messages around quickly is our business. I don't think it's crazy-go-nuts that we've spent some time on an MQ.

I hope my colleagues and I have been able to answer some of your questions. As I said, in the future, please consider emailing us so we can share our experience. Then, we can have a public discussion about facts, not speculation. Perhaps, as commenter sethladd suggested, the onus is on us to produce a whitepaper or presentation about our findings so as to stave off such speculation. Time constraints are the main reason why we haven't done so.

[1] http://al3x.net/2009/04/04/reasoned-technical-discussion.html
[2] http://blog.obiefernandez.com/content/2009/04/my-reasoned-response-about-scala-at-twitter.html#IDComment18212539

Comment Here is an interesting discussion on alternatives (Score 5, Informative) 324

http://unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-mistakes.html

This blog post takes the attitude that Twitter didn't move to Scala because ROR had a problem, but because the in-house messaging system Twitter created performed poorly. The author does not work at Twitter but many of the Twitter developers (including Alex Payne) respond in the comments. I found the article to be very interesting and the comments even more so. They give a sense of how much research Twitter did before this change.

Slashdot Top Deals

But it does move! -- Galileo Galilei

Working...