Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment Re:It could also... (Score 1) 602

I didn't know the strike had that effect on the Dead Zone and 4400. Dead Zone was drifting away from interesting to me at the end. But 4400 that was a great show. Each season had a powerful concept arc that really drove the story forward, I thought. When you think of trying to do an X files type show or the like, it is challenging to come up with big story arcs that you can do from year to year but still add something to the episodic shows in the middle. You can go full on vision like Lost where it is mostly mapped out ahead of time. Or like 4400, each season had a big arc that also drove the shows in between. The first season you are just trying to find out what happened to the 4400 people. The season finale basically tells you. The next season drives on from there exploring the impact of the 4400. They had good arcs about the reaction of the government, the organizing of the 4400. Different factions, key characters growing in power and importance. Major changes to the status quo of who has powers and what that means. Right up to the last episode.

I miss that show.

Comment Re:Rather simple fix (Score 1) 185

Yes, I was also thinking you could use the length of time as an added decision point. When a particular choice is being made the user would have to wait a second or two before entering it. Anything before that wouldn't work. You have the user choose how the time sensitive entry would work beforehand and give very few clues on the screen when it is happening.

For example, I could set things up so that when I'm entering my password, the last two keys have to be separated from the others by a timespan of between two seconds and four. It wouldn't help if someone was watching you do it, but it would help obfuscate how smudges are read after the fact to guess a password. Nothing about the smudges should indicate when they were pressed. I guess if you were doing some heat signature analysis for the fading heat of the finger press, you might be able to glean that. But that seems like an awful lot of trouble to go through and you would need full access to the device shortly after its use to even do that.

Comment Re:I would congratulate them too (Score 1) 198

My own story is somewhat more embarrassing. I think it is safe to say, there are plenty of things about networking that I don't know. So, when I had to decide how to setup my own WiFi, I referred to a copy of 2600 I had that detailed instructions on hacking WiFi networks. Whenever the article said that getting around some security feature was out of the scope of the article, I made sure I turned that feature on. I'm sure a really good hacker could get in anyway, but at least he/she would need something better as a reference than the article I had read.

That part worked fine. But this year we had a big snowstorm (East Coast). The power went out for a while one night. When it came back, I discovered during shoveling breaks that the WiFi was down. So, one day I want to check my email and I search for local WiFi networks. I found an unprotected one. Unencrypted and still with the default SSID and everything. Just sad. So, I logged in, checked my email. Read the headlines on CNN.com and logged out. Smugly, I thought I should figure out which neighbor it is, so I could warn them.

The next day, I login to the router to fix my WiFi and I can't get in. My admin password doesn't work. The password was reset to the default password. It turns out the unprotected router was mine! It must have gotten reset during the power outage and I guess subsequent power surge.

Comment Re:Two senses of "closed." (Score 1) 850

Yes, but isn't that the point? We don't have any right to "technological liberty" from the company's perspective. I mean would this whole discussion even be happening if Apple were some small company and the ipod and iphone were niche products without a large user base? I don't think anyone would care that they required using their products (macs and sdk) to write code for their other products (ipods/iphones). Developer's want to write code for their products because they are so widely adopted and offer the capability to use a lot of the functions of the device. And they have an advantageous model for marketing and making some profit from that code. So does Android now, but I think it is safe to say the iphone sdk opened up a lot of possibilities first.
(Feel free to correct me, if I am wrong on all that.)

So hypothetically... If Apple's products were a niche market and they could do what they want, is it fair to expect them to change because they were successful and became popular?

I didn't get the heat that people felt about this argument at first, but some of that is because I already have a mac. If I was looking at developing iphone apps and had to buy one just for that, I now see how that would upset a developer.

Still though, big picture it seems to me that Apple has created a market for itself by controlling hardware and software more tightly and ensuring greater reliability and usability in their desktop/laptops. Shouldn't we have all assumed they would want to do the same thing for their mobile products?

I'm not a fanboy of Apple and I'm not excusing all the PR spin they used in this argument. But I'm not sure where this expectation comes from that Apple should do what angry developers demand of them. When that means developers moving to a development pattern where they have no control or even influence.

I don't know, someone convince me I should be more ticked off about this.

It occurs to me that Adobe and Apple might have been able to resolve all of this with some agreements to have Adobe adopt all new iphone features in their products in a timely fashion and Apple working with Adobe to give them some lead time for new developments in iphone/ipad etc. Then a little coordination to prevent "flash crashes" and save battery life. But then neither one would have complete control. And maybe the unwillingness of either company to give that up is what this thing is really all about.

Comment Re:It Hurts (Score 1) 320

The almost complete lack of errors and corrections in the text strongly suggest that it's nonsense rather than any kind of encoded message.

Granted, I know next to nothing about this controversy or Medieval history. But before conveniences like the printing press I believe it was pretty common to write out a draft and then copy very carefully the final version without errors. If someone could throw out any pages they made a mistake on, it wouldn't be too hard to come up with an error free manuscript given enough time and attention to detail. Even if the whole thing was done on some kind of prebound book, if someone had alot of practice making careful copies like this and went slow enough, an error free manuscript doesn't seem too far fetched to me.

That's not to say it isn't nonsense, but I don't know that the error rate is that strong an indicator.

Comment Re:Stupid prices (Score 1) 827

Simple. They already got the 14 billion. Now they can do anything they want. The problem isn't the government as an entity being beholden to the cell phone companies. It is that plenty of individual members of congress and the senate get contributions from them and there is no well organized call for reining in their pricing from a consumer special interest group with as much clout as the cell phone companies. As it is, I've heard some members are calling for hearings on unfair text message pricing. That alone means next to nothing, but it is usually how change gets started in Washington.

Comment Re:I don't have anything really smart to say (Score 1) 599

Yes, well I was going for a humorous comment in the "be careful what you wish for" vein. But even so, I'm not sure what scale you are using for the supposed maturation process. Toddler brain at 16, so what 3 to 1? 4 to 1? That means you would have to suffer through those difficult teenage years for nearly 20 years or so?!? I still think I'd stick with the body I've got, old and imperfect though it is. Plus you'd have to expect that unless your parents were similarly slow developing, they would be much more likely to up and die on you before you reached maturity. A long period of foster care could result.

But I guess if everyone was this way and the whole society changed to suit it, you would get a much longer life.
Java

Submission + - Groovy in Action

Simon P. Chappell writes: "I missed the partying in the 70's and so was not exposed to the full groovy experience that was available. You could say that I was a late developer (pun intended). Thankfully, I am now able to make up for lost time by learning the Groovy scripting language. For those of you not familiar with Groovy, it is a dynamic language designed to run on a Java Virtual Machine and be easy for Java programmers to work with; it looks very similar to Java and will freely interoperate with Java objects and libraries. I've been tinkering with Groovy on and off for about two years now; learning Groovy in the old days, prior to this year, was a challenge with all of the design changes that were taking place. Groovy in Action (GinA) is the book that I'd wished was available back then. Dierk König, a committer for the Groovy project, has written this definitive guide to Groovy and after what has seemed an eternity to those of us on the Groovy mailing list, it is finally available.

The obvious candidate for this book is the programmer that wants to learn Groovy. What is less obvious, is just who those people are, because programmers who would find Groovy useful are likely to come from quite a wide selection of backgrounds. If you thought that Groovy wasn't for you, read on and consider whether you may have judged in haste.

Current, or former, Java programmers will love Groovy and they will likely make up the greatest proportion of the readership. They will especially appreciate the interoperability of Groovy with Java: your Groovy objects are Java objects, right down to the bytecode level.

As a dynamic language, Groovy attracts a good quantity of the traditional users of scripting languages. Expect to see more than a few system administrators and build managers pick up on Groovy as they realise the benefits it brings. Further sweetening the pot, for build managers, is the ability to use Groovy as a scripting language within Ant. Another group of readers may well come from the dynamic language communities. I think that Ruby and Python programmers may well find this an interesting book to help them understand this new arrival on the scene. With the steady maturing of the Grails project, that uses Groovy as it's implementation and development language, even the Ruby on Rails folks might be curious.

For a book that's setting out to teach you a programming language, the structure is fairly standard. The contents are divided between three parts that theme the Groovy Language, the Groovy Libraries and then wrap up with Everyday Groovy. I like the approach of including guidance for using the language after you've learned it, because it acknowledges that the purpose of learning a programming language is to then use it. This is a very welcome development in programming language books; other publishers and authors please take note!

And now, for the purpose of full disclosure: Of course this is such a good idea that it blew my book idea out of the water; I had been talking to Manning about writing more of a practical how-to book for Groovy, but with GinA being so good, those conversations stopped almost as soon as they got started.

The first chapter is the standard fare of what Groovy is and why you want to use it. This is important material for those who may be new to the language and it's covered very well. Some book's initial chapters can be a little dry, as if the author was in a hurry to get to the good stuff, but here, Mr. König has recognised that the language is in an early enough phase that explaining why you would want to use it is the good stuff.

I'll save you from a big list of chapter headings and just relate that part one covers the basics, including how to compile and run code and how to run it as an interpreted script. The fundamental Groovy datatypes are introduced and we learn about the joys of optional typing, for those occasions when it's not obvious that the object is a duck. Groovy has all the things you'd expect from a dynamic language: strings, regular expressions, ranges, lists, maps, closures, control structures and finally, to make it in the corporate programming world these days, it has objects.

As we skipped chapter headings for part one, I'll follow precedence and skip them for part two as well. Part one taught us the basics of the language, part two looks to help us now integrate with the Java environment and existing Java code and systems. Builders are an important part of using Groovy to it's full dynamic extent and these are covered extensively. Groovy also brings it's own library extensions for the standard Java libraries, and they are known as the GDK, even though they're technically not a development kit. Groovy works nicely with databases and is able to use any existing JDBC drivers you may have. XML, whether you love it or hate it, is a big part of the life of a corporate programmer these days. Groovy has built in smarts for working with XML and you'll learn about those in this part. There are many useful Java tools, libraries and frameworks available today and Groovy can work with almost all of them. Much good information on integrating with everything from Spring to the new scripting interface defined by JSR-223 is covered.

Part three is the Everyday Groovy part. It starts with Tips and Tricks. Things to remember, useful snippets of code, advice on calling Groovy from a command-line, and writing automation scripts. There's also a full chapter on Unit Testing with Groovy, covering testing of both Groovy and Java code. The last two chapters cover optional stuff for Groovy. Groovy on Windows looks at the use of the Scriptom tool for those who use Windows. (As a Mac user, I admit that I skipped this one.) The last chapter is an introduction to Grails, the web application framework written in Groovy and which can run in any standard J2EE environment.

There are a couple of slim appendixes at the back with installation information, language information and an API Quick Reference for the GDK.

There is much to like about GinA. Mr. König and his co-authors writing is clear and engaging and Manning's layout and typography are up to their usual excellent standards. On it's own, these are good reasons to consider this book if Groovy interests you, but when you mix in the fact that Mr. König is a committer on the Groovy project and has taken an active role in the creation of the language itself, then you have a very compelling reason to choose it.

Groovy in Action is an excellent book, written by one of the designers of the Groovy language. If you have any interest in modern scripting languages at all, I would recommend that you check out this book."

Slashdot Top Deals

"'Tis true, 'tis pity, and pity 'tis 'tis true." -- Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_

Working...