Overall, this looks like a very versatile tools for programmers and everybody else who wants to easily share short snippets of code.

Snipt.net

Of course, there is also snipt.net, which is not related to snipt.org at all (at least as far as we can tell), and which focuses on creating a repository of code snippets. Snipt.net does not feature any Twitter integration, though, according to the snipt.net team's latest Twitter updates, they are thinking about this.

The highly anticipated general release of StackOverflow, the social site for programming questions developed by rock star programmers Joel Spolsky and Jeff Atwood, hasn't happened yet - but the doors are cracked open and many new users are streaming in this morning.

The Big Idea

The idea behind StackOverflow is to offer a really well designed site where programmers can find answers to questions that are more obscure than they can get answered elsewhere. Site founders Spolsky and Attwood are software gurus focused on developer relations and user experience. They've got a very capable team with them as well, as is evidenced by the product so far.

The community is for developers working in any programming language and use of the site is completely free. The name StackOverflow refers to an infinite loop or recursion in the programming languages C or C++ and sure enough, a lot of the conversation on the site is self referential so far. The team's got plans for that, though, so we're confident this will be less the case than it is on other sites.

So far, we like it a lot. What does it look like? Check out these screen shots.

Screen Shots

The front page.

My Question Got Answered!

I got a good answer to an admittedly simple question, in 2 minutes. Awesome.

Asking a Question.

Pretty smart UI here, quite helpful and fun to use.

A User Profile

Above, the top half of a user profile, below the bottom half. Note that you can see how often a user votes things up or down but you cannot see specific voting history. The user feed is nice.

Our Thoughts

The UI here has lots of really nice little touches, it's responsive, communicative and relatively clear. We like it a lot and that was one of the site's big goals, to build an effective UI.

Account creation looks very good, it happens automatically via cookie until you register, but OpenID association with your account is not implemented particularly well. Attwood is blaming OpenID providers for that on Twitter, but we're seeing a few too many problems to buy that.

There's already an active community of beta testers on the site and they've developed extensions like a Firefox and IE7 search plugin, a couple of Greasemonkey scripts and a Ubiquity script. That's pretty awesome.

There's a sophisticated credibility system at work here, where users who build up their reputation are given new capabilities. Those capabilities include commenting on questions instead of just answering them and doing some moderation.

The "community mode" is interesting, things are wiki style on the site and once a certain number of edits have occurred the original asker of the question no longer owns it - it becomes a community question, with lower credibility thresh holds required for interaction, etc. The Community User username is tied to these threads and acts as an automated bot repairing things like malformed tags through out the site. That sounds really helpful.

Finally on the positive side, we got some good replies to our questions really quickly and we're already having a lot of fun just browsing the site.

The Down Sides

We like StackOverflow a lot so far, but there are some real concerns that deserve to be raised. As the site's owners have voiced throughout its development, the quality of discussions may go down rapidly when they open up to the world at large. We hope that's not the case but we will watch the reputation and bios of the people who answer our questions.

More importantly, perhaps, we're not sure the Digg-style home page is the best way to organize these discussion. Is it on the basis of the newness or hotness of questions that things should be ranked? Or should top answers be highlighted? We know that the site's developers have spent a lot of time wrestling with these questions, so we won't pretend to know better, but we hope the core prioritization principles work out well in this context.

There are some features that we expected to see here but don't. An easy way to mark a thread for reading later would be really helpful, as would a feed for those items in our account. A feed for answers given to our questions would be nice. So would the option to get an email notification when one of our questions is replied to, or another question we're interested in. GetSatisfaction's "I'm interested in this too" feature would make a world of sense - let me know when someone else gets an answer to this question because I'm curious. Finally, a "thanks for this" button like Ma.gonlia would make sense and offer a different kind of feedback.

We've already subscribed to the feeds for several topic tags and we're excited about everything we expect we can learn from the StackOverflow community. General availability of the site is expected sometime this week or next.

With Cascada Mobile's platform called Breeze, anyone can take their idea from thought to app in about fifteen minutes. Well, maybe not anyone - the apps are built using HTML, so you would have to have some rudimentary web programming knowledge to use their platform. Still, you have to admit, that's a lot easier than using a professional development platform.

With Breeze, you can build, test, and distribute mobile J2ME apps that run on hundreds and handsets. And these are "real" apps, too - fully integrated mobile applications with their own icon, not just mobile widgets.

The "Breeze Simulator" lets the novice developers test their app for hundreds of different handsets - a usually daunting task in the world of mobile web programming where apps that work on one model don't work on another, even if they're similar in design or from the same manufacturer.

Check out this video that shows Breeze in action:
Cascada Mobile Breeze from Cascada Mobile on Vimeo.

In addition, Breeze developers will receive a line of code they can put on their web sites, blogs, or social network profiles that let their visitors download the app by entering their mobile number. Breeze takes care of the distribution via SMS, WAP Push, and direct download. To subsidize the cost of distribution, the apps are ad-enabled. However, developers wanting to go ad-free can pay for the use of Breeze in order to do so.

Should Programming Be Left To the Professionals?

So, now we have an application that lets everyone program web apps (Iceberg) and a platform for building mobile J2ME apps, what's next? If this trend is to continue, the next big move would be to let novice developers build their own iPhone applications, you would think. But the real question is do we actually want amateurs building apps for our mobile devices? Or would you rather that was left to professionals?

You can try some Breeze applications for yourself from here. (Ooh, mobile Twitter!)

Learning Iceberg is relatively easy - Byrne says "20 minutes and you can be a programmer" - I'd argue it's a bit more than that if you haven't ever been exposed to any programming concepts, but it's far from impossible. To get you started, there's a vast and well-documented training section available from Iceberg's web site, which includes free sample applications, step-by-step guides, screenshots, diagrams, videos, and more.

Build an App in 3 Minutes

As far as what you can build with Iceberg, it's really up to you. Although the focus is on business applications, like CRM or PM tools, you can interface with anything that offers up a web service. For enterprise environments, instead of using Iceberg as a service, I.T. departments can download and use Iceberg offline, behind the firewall, to work with their in-house servers, like Windows SQL server for example.

For companies making an investment in using Iceberg, the team will even go a step further than just providing the service, but will also work with the business to help them with the process of building and customizing their apps. Several of the companies out of the 2000 or so downloads Iceberg has had to date have had this type of assistance, including companies that have moved from Zoho's CRM to their own personalized version.

Today, Iceberg is revving up to a new version: Iceberg 2.1. In this latest iteration, there are new features like a getting started wizard that makes creating applications as simple as answering simple questions about their business needs. They've also added a bug tracker, a more flexible interface, and a new embed feature that lets you "mashup" snippets from any web site or widget right into your form or application.

Google Maps Mashed Up in Form

They've also introduced what they're calling their first "killer app," a project management application for any design/development agency. With this app, users can manage projects, get intelligent estimates based on history, interact with clients, view charts, and more. Unlike with Basecamp, for example, emails are built into the system, you can automatically track and refer to all the communication about the project with ease.

Email functionality in Iceberg's PM App

If you've already written off Iceberg as just another business/enterprise app and therefore not for you, then you're missing the bigger picture. Of course, Iceberg is offering tools for business - that's where the money is - but it's also offering tools for the everyman/novice programmer. Want to build the next great Twitter app?  You can use Iceberg for that...but you can also use it to build the next Twitter, too.

If you want to try Iceberg today, you can download it from this link here for a special deal. The download includes 5 licenses, but if you choose to tell your friends about Iceberg, then you can get access to 2 more free licenses, as will your friends.

1. Loves To Code
2. Gets Things Done
3. Continuously Refactors Code
4. Uses Design Patterns
5. Writes Tests
6. Leverages Existing Code
7. Focuses on Usability
8. Writes Maintainable Code
9. Can Code in Any Language
10. Knows Basic Computer Science

1. Loves To Code

Programming is a labor of love. Like any occupation, truly great things are achieved only with passion. It is a common misconception that writing code is mechanical and purely scientific. In truth, the best software engineers are craftsman, bringing energy, ingenuity, and creativity to every line of code. Great engineers know when a small piece of code is shaping up perfectly and when the pieces of a large system start to fit together like a puzzle. Engineers who love to code derive pleasure from building software in much the same way a composer might feel ecstatic about finishing a symphony. It is that feeling of excitement and accomplishment that makes rockstar engineers love to code.

2. Gets Things Done

There are plenty of technical people out there who talk about software instead writing it. One of the most important traits of a great software engineer is that they actually code. They actually get things done. Smart people know that the best way to solve problems is go straight at them. Instead of spending weeks designing complex, unnecessary infrastructure and libraries, a good engineer should ask: What is the simplest path to solving the problem at hand? The recent methodologies for building software, called Agile practices, focus on just that. The idea is to break complex projects into short iterations, each of which focuses on a small set of incremental features. Because each iteration takes just a few weeks to code, the features are manageable and simple. Teams that follow agile practices never create infrastructure for its own sake, instead they are focused on addressing a simple set of requirements. The secret is that when this approach is applied iteratively, a rich, complex piece of software arises naturally.

3. Continuously Refactors Code

Coding is very much like sculpting. Just like an artist is constantly perfecting his masterpiece, an engineer continuously reshapes his code to meet requirements in the best possible way. The discipline of reshaping code is known as refactoring and was formally described by Martin Fowler in his seminal book. The original idea behind refactoring was to improve code without changing what it does, moving pieces of the software around to ensure that the system is free of rot and also does what it is supposed to do based on current requirements. Continuous refactoring allows developers to solve another well-known problem - black box legacy code that no one wants to touch. For decades engineering culture dictated that you should not change the things that work. The issue, though, is that over time you become a slave to the old code, which grows unstable and incompatible. Refactoring changes that, because instead of the code owning you, you own the code. Refactoring establishes ongoing dialogue between the engineer and the code and leads to ownership, certainty, confidence, and stability in the system.

4. Uses Design Patterns

Ever since the so called Gang of Four published their famous Design Patterns book, world-class engineers have been talking about patterns. Patterns are ubiquitous in our world - both in nature and all human endeavors; software engineering is no exception. Patterns are recurrent scenarios and mechanisms that live across languages and systems. A good engineer always recognizes and leverages patterns, but is not driven by them. Instead of trying to fit the system into a set of patterns, the engineer recognizes opportunities in which to apply patterns. Applying a pattern ensures correctness since it leverages existing know-how: a method for solving a particular engineering problem that has worked before.

5. Writes Tests

Long gone are the days when engineers thought of testing as beneath them. After all, how can you be certain that your code is actually working if you never test it? An agile practice called Unit Testing has recently gained popularity because it focuses on writing tests to mirror the code. As the system grows, the body of tests grows with it, providing proof that the code actually works. Experienced engineers know and understand the value of tests, because their goal is to create a working system. Good engineers will always write a test once a bug has been exposed to make sure it does not come back again. But a good engineer also knows not to waste time writing trivial or redundant tests, instead focusing on testing the essential parts of each component.

6. Leverages Existing Code

Reinventing the wheel has always been one of the biggest problems in the software industry. From inventing new languages to rewriting libraries, the strange drive to ignore and redo what is already there and already works has been the cause of a lot of software failures. A rockstar engineer will focus on three essential kinds of reuse. First of all, the reuse of internal infrastructure, the code that he and his peers have written. Secondly, the use of third party libraries, for example, in Java, the libraries that are part of JDK or popular libraries provided by the Apache Foundation. And finally, a good engineer would look to leverage web-scale web service, like the ones offered by Amazon. Correct leveraging of existing infrastructure allows rockstar engineers to focus on what is most essential - the application itself.

7. Focuses on Usability

Good engineers always focus on the users. Whether the user is a business or an individual, whether the engineer works for a consumer software company or an investment bank, the focus is on working, usable software. How will users interact with the system? Does it provide a simple, intuitive, and smooth experience? The notion that because a software engineer is a techie, he or she thus can not relate to how other people interact with the system is deeply flawed. Good engineers work hard to make the system simple and usable. They think about customers all the time and do not try to invent convoluted stuff that can only be understood and appreciated by geeks.

8. Writes Maintainable Code

The other secret of good engineers is that it takes the same amount of time to write good code as it does to write bad code. A disciplined engineer thinks about the maintainability and evolution of the code from its first line. There is never any reason to write ugly code, a method that spawns multiple pages, or code with cryptic variable names. Rockstars write code which follows naming conventions, code which is compact, simple and not overly clever. Each line of code serves its purpose and resides in the right place. The bits that are difficult to understand are commented, but otherwise naming conventions are clear. Expressive names for methods and variables can make the code self-explanatory.

9. Can Code in Any Language

A good engineer might have a favorite programming language but is never religious about it. There are many great programming languages these days and to say that you only can code in one of them is to demonstrate a lack of versatility. In Java, C#, or C++ you can write any modern software. You can code the back end of any web site in PHP, in Perl, or in Ruby. At the end of the day, the language does not matter as much as the libraries that come with it. A good engineer knows that and is willing and able to learn new languages, new libraries and new ways of building systems.

10. Knows Basic Computer Science

The last, but certainly not the least trait of a great engineer is a solid foundation. A good engineer might not have a degree in computer science but must know the basics - data structures and algorithms. How can you build large scale software without knowing what a hashtable is? Or the difference between a linked list and an array? These are the basics that everyone should know. And the algorithms are just as important - from binary search to different sorts to graph traversals, a rockstar engineer must know and internalize the basics. These foundations are necessary to make the right design decisions when building any modern piece of software.

Conclusion

There are many traits that distinguish great software engineers. Among the ones we discussed, passion is certainly very important. Knowing the basics like code reuse, design patterns, fundamental data structures, and algorithms is necessary, while agile practices of refactoring and unit testing help engineers iteratively evolve complex software. Most importantly, rockstar engineers believe in simplicity and common sense. It is these beliefs that help them succeed in building the seemingly impossible, complex software systems that are necessary in today's world.

Let us know what other traits you think a rockstar software engineer should have, in the comments below.

And then what happens?

Programs will fail, of course. Since they will see times not as being in 2038 but rather in 1901, erroneous calculations and decisions will occur. (It's true, I checked Wikipedia!)

We've actually seen fallout from the 2038 bug already, back in May of 2006 when the AOLserver web server software crashed. The software was designed so that database requests would "never" time out. Instead of assigning a "0" to the timeout, the software specified a timeout date one billion seconds in the future. One billion seconds (just over 31 years 251 days and 12 hours) after 21:27:28 on 12 May 2006 is beyond the 2038 cutoff date. The system calculated a timeout date that was actually in the past, got confused, and crashed.

The bug even affected the Mars Rover!

Want More Proof?

Check out the archived outputs from test scripts here:

• http://www.lugmen.org.ar/pipermail/lug-list/2005-May/035318.html
• http://www.sec.org.il/coverages.php?c=53
• http://unix.derkeiler.com/Mailing-Lists/AIX-L/2004-01/0011.html

What's Affected?

By 2038, it's likely that many of the susceptible machines will have been decommissioned before the critical date occurs. However, legacy systems and embedded systems could still be affected. These may include process control computers, space probe computers, embedded systems in traffic light controllers, navigation systems, routers, gas pumps, etc. It may not be possible to upgrade many of these systems, so they will need to be replaced.

I'm a Programmer - What Can I Do?

• Test your code or use utilities such as the FakeTime Preload Library.
• See the programming recommendations from The Open Group (formerly X/Open), which maintains the Unix specification and trademark.
• If you're working with Open Source code, this free library may be a useful reference for patching existing code for high-accuracy longterm time calculation.
• Read the Solutions to the Year 2000 Problem by Steve Manley. Many of his suggestions can be applied to the 2038 problem, too.
• Keep tabs on any recent updates on the 2038 Bug web site

(Source: the 2038 FAQ)

The End?

Before mass hysteria sets in, let's all remember that we have years, decades even, to deal with this latest programming glitch.

Well, I'm pretty sure that self-improving Artificial Intelligences will be running the world by then, so we probably don't need to worry too much about this.

(via guardian.co.uk)

]]>Discuss]]> http://www.readwriteweb.com/archives/the_internet_will_end_in_30_years.php http://www.readwriteweb.com/archives/the_internet_will_end_in_30_years.php Trends Thu, 13 Mar 2008 14:00:00 -0800 Sarah Perez