Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

It seems to me that what the OP really should use is a mature framework e.g. Drupal rather than rolling your own regardless of language choice.

BUT since this thread has evolved into a language choice I'm going to respond to that. I'm also going to come right out and say that this post will be very unpopular on Slashdot. [Hopefully I won't get sunk by too many mods saying -1 "opposite of my fanaticism." ] ColdFusion has a pretty narrow applicability, but it's ideal for the OP.

Con: ColdFusion per se is not free in source or beer. (allthough there are ports) BUT shared hosting is only infinitesimally more expensive, so this is an issue only if you'relocked into a certain host or you are goign to have aan armada of servers. [The local dev version IS free.]

Con: ColdFusion is not very popular. There's still a LOT more usage than most people seem to perceive, but it's obviously not up there with e.g. PHP. [Commercially ColdFusion missed its window. In ~1998 database driven web applications were relatively novel and it was awesome. In 2001 it was comparatively unstable at higher traffic values. In 2002 they threw out the underlying server product and now it's an interpreter plugin that runs on any J2EE server you want it to.]

Pro: CF is a mature, modern flexible, powerful, rapid development toolchain for making websites. Especially as a novice in web apps it's going to support you. It'll let you worry about your app and not the minutia and has automatic capabilities for all sorts of things. It does the right thing by default but lets you override if it you need to. [Aside: These advantages are rather similar to what's advertised for RoR which IS free... If anyone can tell me some awesome thing RoR does for a website that CF doesn't beyond the two "cons" I've listed above I'd really like to know -- so far no one has been able to give me a good one. I'm excluding outdated concerns e.g. that the 1999 version of CF wasn't OOP.]

Pro: CFML is a pretty ideal language for generating HTML because as a markup language the flow of your HTML remains obvious and readable. [PHP eventually adopted the ability to use a similar paradigm.]

I've heard some people say that CF is what Java Server Pages should've been.

Pro: CF IS Java. (server) You're running on a Java server and the things you already know about running that remain true.

Pro: CF IS Java. (language) Even moreso, you can literally inline Java code into CF code (much like old school ASM into C). In my time writing CF I've done this literally twice:

a. to use Java's sleep() [Note: I do not recommend using "sleep" when generating a webpage, but it was an exceptional circumstance.]

b. to use Java's image manipulation libraries from CF templates.

I'm not saying CF is ideal for all circumstances. Merely being non-free rules it out of a lot! But it really is -- at least in my opinion -- "how to build a web app on a Java server" and that has a lot of suitability as a platform for the OP.

New submitter GrantRobertson writes with a question about quickly developing prototypes for new interface design concepts "My research/tinkering will be along two main lines: (1) Devising entirely new graphical user interface elements, mostly in 2D, though often in a true or simulated 3-D space. I am working on ways to visualize, navigate, and manipulate very, VERY large data-sets of academic research information. (2) Computer based education software, though of a type never seen before. This will combine some of the GUI elements invented in (1) as well as displaying standard HTML or HTML5 content via a browser engine My requirements are: (A) A decent IDE ecosystem; (B) A decent set of libraries, but ones that don't lock me in to a particular mind-set like Swing does in Java. (Boxes in boxes in boxes, Oh My!); (C) An ability to easily draw what I want, where I want and make any surface of that 3D object become a source for capturing events; (D) Ease of cross-platform use. (So others can easily look at my examples and run with them.); (E) No impediments to open-source licensing my code or for others to go commercial with it either (as I have seen when I looked into Qt). So, should I just stick with Java and start looking outside the box for GUI toolkits? Or is there something else out there I should be looking at?"
I'm not sure what impediments Qt has to proprietization of software since it's LGPL nowadays; in any case, Qt Quick and GNOME's Clutter seem like they could be a useful. Read on for more context.

New submitter datavirtue writes "I'm about to embark on developing active content (database driven, and web services) for the first time for my website and I have grown to love PHP. Knowing that there are other web development platforms available, and noticing some disdain for PHP in some circles, I'm curious to know which platforms slashdotters prefer along with the reasons why. Before I get started into heavy development I would like to get some opinions and more facts. Why shouldn't I use PHP?"

smitty777 writes "Reuters reports that a quarter of the EU has yet to use the internet. Further, half of those in some of the southern and western states do not even have internet access at home. From the article: 'As well as highlighting geographic disparities across one of the world's most-developed regions, the figures underline the lack of opportunity people in poorer communities have to take part in advances such as the Internet that have delivered lower cost goods and service to millions of people.' The full report created by Eurostat can be found here."

snydeq writes "Despite early successes on the Web, the latter years of Flash have been a tale of missed opportunities, writes Fatal Exception's Neil McAllister. 'The bigger picture — which I've touched on before — is that major platform vendors are increasingly encouraging developers to create rich applications not to be delivered via the browser, but as native, platform-based apps. That's long been the case on iOS and other smartphone platforms, and now it's starting to be the norm on Windows. Each step of the way, Adobe is getting left behind,' McAllister writes. 'Perhaps Adobe's biggest problem, however, is that it's something of a relic as developer-oriented vendors go. How many people have access to the Flash runtime is almost a moot point, because Adobe doesn't make any money from the runtime directly; it gives it away for free. Adobe makes its money from selling developer tools. Given the rich supply of free, open source developer tools available today, vendors like that are few and far between. Remember Borland? Or Watcom?'"

Hugh Pickens writes "Ted Dziuba has an interesting and amusing post on how he made a big mistake when he was offered a choice for his company laptop. His options were a Lenovo Thinkpad or a MacBook Pro, and he picked the Mac, thinking it would be closer to what he was used to. So what's wrong with using the Mac as a development machine for Milo, a Python application backed by PostgreSQL and Redis? 'I've only poked around a little, but so far I've found three separate package managers for OS X: Fink, MacPorts & Homebrew,' writes Dziuba, adding that when you are older, you will understand the value of automated version dependency satisfaction. Next is that your development platform should be as close as possible to your production platform, but 'OS X and Linux have different kernels, which means different I/O & process schedulers, different file systems, and a whole host of other implementation details that you'll write off as having been abstracted away until you have your first serious encounter with "It Works On My Machine.'" Finally, he says, Textmate sucks. 'Sooner or later, you have to face facts. Man up and learn Emacs.'"

I realize you asked for a ruggedized laptop. However, that everyone else replaces theirs regularly points to the idea that you should consider that as a serious alternative and not discard it out of hand. I called this 'out of your box' because they're all doing it, and you're rejecting it a priori. I see basically three legitimate issues with this solution:

a) maintaining a consistent interface for you to be used tob) providing easy data migration to the replacement devicec) total cost of multiple non-ruggedized devices compared to the realistic lifespan of ruggedized ones.

I'm not suggesting that my parent post had the right thoughts in mind, but Apple does provide surprisingly good, quick and easy solutions for a&b in OS X and the iPhone; I would expect the iPad to continue this.

Apple is not historically great about 'c', but that sand environment is hard even on the modestly ruggedized ones so it's not impossible.

Of course, I imagine their are.e.g Linux distros with good solutions to a & b and other laptop vendors who tend to have a consistent interface.

Of course you might need to account for shipping, purchasing, processing, or environmental costs in 'c', but even on the environmental front it's not a given that one device is better than 3, esp if it gets recycled well (many parts of the sandworn one will still work, and it'll be early enough that those, minus your HD, are reasonable used replacement parts in the right shop...)

I'd go further and say that in my opinion, and especially at these dataset sizes that are only small multiples of physical drives these days, RAID5 is a hinderance not a benefit to price-performant backup, because it requires validity of all-but-one of the drives in your array... typically, in the CORRECT array, so swapping mirrors in/out may be quite a headache.

Don't use any data level striping; break your data into a couple chunks drive-sized in the filesystem. Keep mirrors of each chunk on drives, both onsite and (one or more) offsite. Bit-compare the drives occasionally to look for loss.

I recommend at least 3 drives for any dataset; at least one onsite and at least one in your lockbox; that leaves one to be in transit at a time.

Replace the drives with newer versions every few years. Use a variety of brands/models.

Archival quality printing is also not cheap, but at least it's a fairly solved problem.

Personally I don't think you can do much better than printing it for an option that doesn't involve frequent migration - density isn't great, but I'm confident there'll still be optical scan devices at least for historical works, so if you print out all your bits in an OCR-friendly font, it won't be TOO much work for someone else to read them (if they really want to!) You should also include in the same format the source code for the decoder - even if that's not directly compilable in the future, it'll be a relatively clear indicator of how to do it, to the limits of what's possible.

You could probably do even better by e.g. punching holes into gold sheets a la The Baroque Cycle. Or stone tablets, etc. But those are all questions of "what's the most resilient format for PRINTED text" which is a topic at least we have a bunch of data on.

Actually, MS has tried to implement some Trusted Computing pieces that would do exactly that - restrict what will run so any DRM-broken content can't possibly be played.

Perhaps we could amend your sentence to: "never SUCCESSFULLY locked down..." - because they can't manage to have backward compatibility with all the terrible niche Windows apps and also do things like that.

I have no idea what this Orange Goo does, and I haven't read TFA. But I want to comment on your comment:

1) Most electronics are not made with incredibly strong surfaces and shells. If you were to encase your electronics in a perfectly fitting thick walled steel cradle, you'd reduce all events (esp a floor hitting a corner) into only the shock (G force) leaving out the impact (concentration of force on the surface of the device) Both of these parts of an impact are damaging. The fundamental momentum-limit you discuss only applies to the shock, which is most likely to damage internal parts.

2) Some crazy materials can do a surprisingly good job of momentarily pretending to be that idealized steel case. I presume the egg-video above shows that.

3) Typical elastic padding will not spread the momentum distribution out EVENLY over the time it takes to decelerate that 1/8". So even the shock part can be improved.

4) Don't forget that in addition to momentum, you must satisfy the conservation of energy equation, too. The most common way to do this is to bounce, and at least some of this energy gets converted to heat in each material that compresses. Dissipating more energy is also valuable.

Wow, you're amazingly not good at following plot points. Maybe there are holes in the plot, but they sure aren't the ones you listed.

As much as I want to rebut everything in great detail, it turns out I don't care quite enough. So a few... and I'll endeavor not to add any spoilers you didn't already give, and I'm dekarmaing this post to help.

6. Worker Prawns lack initiative. Definitely said early in the movie.

5. is because of 6.

3. If you PROCESS some material/chemical, it probably has different effects/uses than it had before you processed it. Otherwise why would you process it? Did you miss that whole bit of the movie?

2/3. That part about "powering the command module" - you made that up. At no point is powering a command module ever anything any characters are aspiring to. In the interest of avoiding spoilers, I'll leave it to you to figure out which part of those 4 words you might've gotten wrong.

I was going to say this, but of course you beat me to it. District 9 is one of the most legitimate serious science fiction / extrapolative fiction movies I've seen in a long, long time - things you usually only get in books. A limited number of fantastical assumptions, and then the exploration of the very rational ramifications of those assumptions.

And it was made on a relative shoestring, and the effects are perfect -- and the acting is amazing. But if you're expecting a 100% crazy action/effects movie, District 9 isn't it. (Neither is Inglorious Bastards, which is also awesome)