Forgot your password?
typodupeerror

Comment: Re:Irony (Score 1) 816

I had the same reaction when I was a kid and saw The Black Hole. I own it today, and I fully agree it really is a dark sci-fi movie; it's one of my favorites.

Honestly, I prefer it over Star Wars.

As an aside, did anyone else notice that in Tron 2, when Flynn's son first enters the virtual world, makes his way onto the 'command ship' and meets (I think) CLU for the first time that the command room looks exactly like the command room on the Cygnus from the Black Hole? The little pods sunken into the floor and the ledge going around the edge? Is it the same set? I always sort of wondered if that was a nod to the other movie.

+ - Disney buys Star Wars->

Submitted by bomb_number_20
bomb_number_20 (168641) writes "Disney has just confirmed that it has agreed to acquire George Lucas‘ Lucasfilm Ltd, and that includes rights to the Star Wars franchise that will now continue on. The companies have targeted a 2015 release for Star Wars: Episode 7, with Episode 8 and Episode 9 to follow as the the long-term plan is to release a new feature every two or three years. “The last Star Wars movie release was 2005’s Revenge Of The Sith – and we believe there’s substantial pent-up demand”, Disney said. The deal also includes rights to the Indiana Jones franchise."
Link to Original Source

Comment: Re:any questions? (Score 2) 360

by bomb_number_20 (#41748631) Attached to: Ask Slashdot: How To Avoid Working With Awful Legacy Code?

I used to think this way, then grew up and realized that tools like IntelliJ and Eclipse are useful and have features that give me more insight into the code I'm working with and help me do my job more effectively. The tool is just a tool, and any tool will let you do things you're not supposed to do if there are not processes in place to prevent it. This is where the attitude of the business, coding conventions, code reviews, unit tests and other processes come into play.

Put more simply- if this were construction, I'd say it's not the hammer's fault the house was poorly built.

Comment: Re:Curious (Score 1) 445

by bomb_number_20 (#38924541) Attached to: Ask Slashdot: Are Daily Stand-Up Meetings More Productive?

I know. I was actually just trying to put into words the ridiculous cartoon that was in my head.

You raise an interesting point. I think the scenario you describe is an ideal situation for something like that, and there's value in it because you're communicating information to another group. I agree that ritual for the sake of ritual is meaningless.

Maybe the difference is that, with a morning standup, you are essentially giving yourself a shift briefing on the work you just did the day before. That alone could make it meaningless. Maybe the value of the morning meeting is proportional to the communication dysfunction within your company?

Comment: Re:Curious (Score 3, Funny) 445

by bomb_number_20 (#38924129) Attached to: Ask Slashdot: Are Daily Stand-Up Meetings More Productive?

Not even close to the same thing.

Well, not unless every person in your morning company formation sequentially breaks ranks, runs to the front, does an about face and gives a personal status:

"Company! Yesterday, I did a lot of pushups! Then I low-crawled! Then I cleaned my weapon and did some more pushups! Today, I'm going to walk a lot! My impediments are the group of people across the wire trying to kill me! Hoooahh!!"

Comment: Re:Agile is only for production, not R&D (Score 1) 60

by bomb_number_20 (#35911584) Attached to: Book Review: Agile Development & Business Goals

I agree with your sentiment.

I'll veer off into the woods a bit. At my company, we recently switched to scrum and it gives clear visibility into who is adding all the extra, unnecessary work and scope creep that comes with people not quite doing what they are supposed to be doing. What I really like is that it also gives developers a tool to push back with when they are asked to switch contexts, re-prioritize what they are doing or take on new work via scope creep.

Team structure seems to play a larger part in things than I hear people talk about. Trying to find a balance between inexperienced and experienced developers is difficult, and we've pretty much always come up on the wrong side of it. One of the other fundamental imbalances I've seen (at least in our organisation) is that, within the context of a sprint, the developers are usually capable of doing everyone else's job- but the reverse is not true. I've seen this turn into situations where developers end up doing BA work, QA work and supporting production issues while trying to keep up with the development tasks that are on the board. Meanwhile, everyone else is just sort of sitting around, trying to look busy. In my opinion. this is a management failing more than anything, but it is still an imbalance.

This could just be how we apply (or misapply) things, but what I really wrestle with is the idea that ultimate accountability seems to rest with the developers, but others don't seem to be held to the same standard. Agile (I can only speak to scrum) seems to provide a framework that offers to give developers more power in exchange for more accountability- but none of the processes that give the developers what they really need to deliver on what is required seem to fall under that same framework. Scrum seems to declare things like figuring out specific requirements for what you're trying to develop outside it's scope. This means that when other areas of the business don't do what they are supposed to, the developers end up having to deal with it in some capacity. Since they are the ones on the hook, that usually means doing someone else's job. Developers are motivated by the sheer number of eyes focused on them, but where is the motivation for everyone else involved in the process? Even this book review seems to only talk about rewarding (or not) developers. There isn't mention of the other groups that feed the process.

I'd also go waaaay out on a limb and argue that misapplied agile seems to have the potential to kill vision within a company. By forcing people to spend the majority of their time thinking only about what they can deal with in terms of this (or the next) sprint, it seems long-term vision with respect to a product has the potential to get lost. In other words, if there isn't a cohesive vision of what you're trying to produce, you could be reduced to a team of developers who only have the ability to react to situations and stare at the technical debt you've accumulated by switching directions so many times. That's probably a bit melodramatic- maybe that potential exists regardless, but scrum makes it easy to see how that could happen.

Ok, enough ranting.

Comment: Re:Why only ASCII? (Score 1) 343

by bomb_number_20 (#34592776) Attached to: The Case For Lousy Passwords

Part of the reason may be that the back-end storage for that particular site is a legacy system and limiting users to ASCII characters ensures that the byte length of all entered characters is exactly the same. Otherwise, a user might be using a charset that provides for umlauts or something. In UTF-8, for example, the higher order characters could use 2, 3 or 4 bytes of storage.

Assuming you are on a website, your password could still pass form validation because the character length passes muster, but behind the scenes you are using more bytes than anticipated. This could cause the stored data to extend beyond the length of the column, causing the DB to truncate the stored password and therefore corrupt it.

You are an insult to my intelligence! I demand that you log off immediately.

Working...