Mobile computing is on the rise, and gaming is a strong component of it. There is a toolkit that will let you program in LUA (fairly common in game engines these days) and it will generate programs for both iPhone / iPad and Android at the same time. Programming is simple and the new game engine employs physics and other gizmos.

See game release: http://blog.anscamobile.com/2010/09/theyre-here-corona-sdk-and-corona-game-edition/

Video: http://www.youtube.com/watch?v=0e4p_5J_bZY

Having access to and mutilating the environment are two completely different things. Treating developers as hostiles by server admins doesn't create the friendliest work environment.

There is a big difference between a bug and the reason why the bug occurred - having access to a production environment is paramount to understanding the underlying issue.

In most newspaper sites the headline / lede / seo field / first graf may is usually programmatically brought in as the META description for SEO purposes (unless specifically overridden). It's a fairly common assumption that this field would be pure text and overlooked in that it doesn't need sanitization. Of course, it's also a fairly common consequence that some silly editor eventually breaks the site by putting HTML code in fields they weren't meant to house. You'd be surprised how many (even big) media sites fail to sanitize these fields.

Onto my point: having HTML (or faulty HTML for that matter) inside a HEAD description field seems like a bug. Sure, you can replicate the error by copying the environment and fix it by stripping anything unexpected out. However - that may not be the root of the problem. Thus, developers end up putting bandaids on a system and treating symptoms rather than curing the problem.

When copying this environment to reproduce the issue, one might simply grab the part that's affected, ignoring the user - CMS preferences which would actually end up telling you what the problem was. What a developer SHOULD do instead is poke around the environment, notice that this was a common occurrence with particular users, talk to the editors in question and shadow them for awhile to understand why this sort of thing keeps repeating.

In many cases, I've seen editors take advantage of programming or security holes to produce far richer and personalized web content than the original design or system permitted. By treating this problem out of the production environment context, the editorial side is completely cut out of the feedback and has no say in the matter and their creative outlet disappears with no dialogue. This in turn breeds hostility and distrust between technology and content.

I can assure you that in reality there is minimal dialog between developers, designers, project managers - and - editors. In my past experience access to the production environment was the only means of lateral communication between abstract technology and persons who use it. In my cases, I've been able to provide editors with features they hesitated to request to circumvent problems while still tightening various holes. This, in turn, improved everyone's day.

Look at it from a philosophical view- you don't want developers to be "writin' them codes" in vacuum of non-editorial space. They need to be a bit more intimately involved with the entire publishing cycle from start to end and not be ticket-solving space cadets when it comes to solving problems.

"This year, AOL is spending $50 million to expand Patch nationally to hundreds of sites by the end of the year."

http://www.boston.com/business/technology/articles/2010/08/05/with_patch_aol_offers_challenge_to_local_news/?page=full

AOL is going hyperlocal - going to give local newspapers a run for their money.

I'm glad first responses are so negative; now I don't have to bother trying ROR out.

Actually, they are. The new PHP contribution is NOT efficiency-related. Instead, they built privacy controls into PHP. However, the problem is that by default it's set to open.

When I went, I went along with "old blood." As late (or early) as 2003, the "elites" had disdain for all the "new blood" trash that was amassing. The "elites" had reminisced about the old days when only handfuls would gather and do crazy things like shoot fully automatic machine guns in the desert. Somehow they couldn't put it through their heads that large numbers of people have no sense of either collective or individual responsibility and thus have to be policed.

To me, there is no "radical self expression, self-reliance, creativity and freedom" in this event any longer; however, there are a few *individuals* who have those traits, but all others are audience. The CYA agreement just reaffirms their identity as a corporation.

This wouldn't be a question of data entry. In most cases, the data is already there. All you need is a way to connect it. For example, the U.S. Census Bureau has a list of neighborhoods and their polygonal borders.

Now, the CS students in your reference would simply apply a PIP (point-in-polygon) algorithm to see which neighborhood a particular lat, lon coordinate belongs to.

And since that's computationally intensive, the CS "students" would have to know a bit about optimization - including quad trees, and so forth. Bla.

A smooth line from the Seattle thrift store t-shirt roundup:

"Think your iPhone is cool? Let me show you a thing or two about Windows Mobile."

http://valleywag.gawker.com/5144493/the-shirts-off-of-microsofts-back

While vi and a Web Browser is good enough for some, I'd take just the Web Browser. Rapid development needs to break out of the constant theoretical-writing-uploading/saving-previewing cycle and that's why I put together my "eval2" project for PHP.

This video tells it better:

http://www.youtube.com/watch?v=Yfxrt2pc3pg

While the example is ultra-simplistic, I use this every day for altering regex or otherwise previewing REAL data as I protoype code. Anyhow, the typical horse and buggy mentality backlash against this approach has been "well, I can just do php -a".

For the interested, see http://eval2.sourceforge.net/