In one of the more popular Google I/O sessions of Day 2, two members of the Google [x] team behind Project Glass explained how to enable root access on your expensive eyewear — a step that will also void your warranty, just like it does when you root an Android smartphone.

What does root access do? It lets you tinker under the hood of Glass, allowing you to, for instance, install Linux and run apps tailored to the open-source OS. 

Google software engineers P. Y. Laligand and Hyunyoung Song started with the warranty warning and a quick presentation on how to enable a debug mode that lets you load Android applications (APKs) on Glass. The two stressed that Google recommends this method for tinkering with Glass, as the debug mode doesn't void your warranty. 

It being Google though, the duo hurriedly brushed past the warning. Using a Bluetooth trackpad-enabled keyboard synced to Glass, the engineers outlined five steps involved in rooting Glass: 

1. Access the bootloader
2. Unlock the device & erase personal data
3. Swap out and override boot partition
4. Reboot into normal state
5. Access root mode

Laligand was nice enough to run through a demonstration in real-time. Below are the screens from his fast hack. 

Accessing The Bootloader & Unlocking Device

Reboot To Root 

Success!

In San Francisco Wednesday, Google just kicked off I/O, its annual conference for developers with the audiovisual bombast that's customary at these sorts of events. But underneath the music, behind the pulsing screens, a question lurked: What does it mean to be a "developer"? Who is Google speaking to?

I'd argue that the definition of "developer" is expanding to embrace a larger and larger set of people, people who previously thought of themselves merely as technology enthusiasts or heavy users of technology at home and in the workplace. And Google is at the forefront of pushing this redefinition.

Google executives Vic Gundotra and Sundar Pichai hinted at the expansiveness of I/O's reach. We've heard that some 7,500 developers are registered for this year's event. Gundotra, a longtime champion of developers at Google, noted that 1 million people were watching the live stream. (That's him in the image above.) And Pichai hinted at the explosion of post-PC, post-smartphone, post-tablet devices for which we might build experiences soon: Google Glass, smart watches, and other wearable-computing gadgets.

It's All About The Tools

A software developer, in the Microsoft era, was someone who wrote applications for a desktop PC.

Now, we get computing devices through an explosion of screens, from TVs to big monitors on our desktops to tablets and smartphones. Google Glass and the Pebble smart watch give us even smaller screens—just enough room for blips of information. There are simply too many ways of delivering digital experiences for anyone to dedicate developers to each one.

That means that we need more and more layers of abstraction around the development of software. At I/O, Google showed off one such tool, called Android Studio, which aims to simplify the frustrating process of figuring out what screen an Android user might have. It was launched to big applause.

A new developer console for Google Play, Google's store for Android apps, tells developers when they're getting a lot of users in a specific country—and even offers a translation service to adapt apps to speak those users' language.

But Google also seems to be recognizing that there's a set of people who need simpler tools. Take its mobile content recommendations tool, which people can add to a website with a single line of code, like dropping in a YouTube video.

Think of managing a YouTube channel, or a page on the Google+ social network: Those, too, in a sense are working in code, though at a very high level.

As is anyone publishing a website. Google's tools for webmasters, aimed at helping them make sure users can find their pages in Web search, can be thought of as another form of access to Google's platform. Those are slowly getting woven into Google+, as are Google-linked Android and Web apps, which can now use Google+ to let users log in and share activity with friends.

And for that matter, Android smartphone owners who simply download an app are, when you think about it, reprogramming an incredibly powerful computing device. That's working with code, whether or not they think of it as such.

Services At Your Fingertips

We're only seeing glimmerings of how Google might pull this all together. But consider how, say, a music-video app might interact with Google. It might well use YouTube for distribution and discovery, as well as having a Google+ page. It might use Google+ for sign-in and activity sharing, so when people search for an artist's name, videos watched by friends pop to the top of search results. For mobile, it would certainly have an Android version, sold through the Google Play store, of course.

That's a staggering array of Google services that one app developer might need to touch. And it's hard to imagine that any single developer, or even a team of developers, might be able to learn how to use them in great depth. That means Google will need to deliver more simple ways of accessing the power of its computing platforms.

There will always be a need for highly sophisticated programmers who dive deep into code, plumb the depths of computing architecture, and probe the limits of what's possible.

But for the rest of us, who just want to do something amazing and make use of Google's tools while doing it, one line of code sounds awfully nice.

Photo by Nick Statt for ReadWrite

Welcome to ReadWrite's live coverage of the Google I/O keynote. Below you'll see not only a live stream of the event, but live blogging from our on-the-spot team including editor-in-chief Owen Thomas, mobile editor Dan Rowinski, contributing writer Mark Hachman and our fearless editorial assistant Nick Statt.

Our stories so far:

• In Google's Future, We Will All Be Developers
• Now Google Wants To Kill The Mobile Web (Good Riddance)
• Google Just Launched A Grenade At Spotify — And It Just Might Work
• Google Is Turning Search Into The Planet's Biggest Anticipatory System
• The Future Of Google Maps: Social, Personalized And Way Smarter
• What Google Didn't Announce At I/O
• Google Search Learns To Listen & Understand Context
• Google Is Making Life Easier For Android Developers

For the rest of the live blog coverage, see our real-time posts on the ReadWrite Google+ page.

Physicist and science fiction author Arthur C. Clarke once famously said, “Any sufficiently advanced technology is indistinguishable from magic.” If that’s the case, there’s no reason why science can’t be made as entertaining as a magic show. Especially if you include robots and lasers.

That’s the theory behind STEAM Carnival, a traveling circus designed to introduce kids to the STEM fields of science, technology, engineering and math — plus the arts. (Put the initials together to spell STEAM, get it?) Some 40 different high-tech games and demonstrations will educate and inspire kids by blinding them with science. 

Professional Roboticists!

STEAM Carnival started as a joint idea dreamed up by Brent Bushnell (whose dad is Nolan Bushnell, the inventor of Pong) and Eric Gradman, professional roboticists who made their reputations turning science into art. If you caught OK Go’s famous Rube Goldberg machine music video, you’ve seen their work. In fact, they said that video prompted the idea for the carnival. Steam Carnival's board includes the elder Bushnell, game industry luminary Brian Fargo, and Mythbuster Grant Imahara.

“Some of the most compelling feedback we got from that video was from parents and teachers coming to us, saying ‘We don’t know what our kids learned from that, but they were so excited about engineering when they saw it,’” said Gradman. 

Gradman explained that the goal of the carnival is not only to introduce kids to the potential of engineering, but to show them just how capable they are of picking it up themselves. 

Simple Components Create Complex Machines

For example, he described one attraction — a robot that responds when kids stand in front of it and make gestures. On a table nearby sit all the components that make up the robot, and kids are encouraged to play with them and assemble the parts. Basically, it lets them see that even the most complex electronics are made up of simple pieces. 

"It's like going to a magic show and then as you exit through the gift shop, realizing not only how all the magic tricks worked, but how to do them yourself,” Gradman said. 

STEAM Carnival Is Looking For Funding

Bushnell and Gradman have built the attractions themselves, but now they need the public’s help funding the project. Their Kickstarter campaign, with an initial aim of getting STEAM Carnival to Los Angeles and San Francisco, is already halfway to its $100,000 goal with nearly a month to go.

Until it’s funded, the duo is drumming up interest by presenting a prototype to test audiences of lucky middle school and high school kids in Los Angeles.

Bushnell said educators are always surprised to see how quickly kids become interested in science once lasers are involved. 

“We’re not up there describing dry principles,” he said. “We’re doing demonstrations. It’s a complete left turn for them from traditional education.”

Bushnell and Gradman hope to expand to many cities beyond Los Angeles and San Francisco, but they’ll need STEM educators’ and mentors’ help to do it. If you’re interested in bringing the STEAM Carnival to your city, cast your ballot here.

STEAM Intro video - short from Brent Bushnell on Vimeo.

All images courtesy of STEAM Carnival.

Each year, the U.S. government declassifies thousands of documents and releases them to the public through collections like the Declassified Document Reference System (DDRS) and the CIA's FOIA Reading Room. Some, however, contain "redacted" information that's too sensitive to be released — leaving, for instance, key details of an FBI memo blacked out for the average reader.

Enter the Declassification Engine, which aims to harness Big Data analysis and some old-fashioned crowdsourcing to peer through the "black bars" of redacted documents and reveal what the government doesn't want you to know. 

Using publicly available, declassified documents as its sources, the Declassification Engine aims to eventually make informed guesses about what those black bars are hiding, providing a "word cloud" of likely possibilities. Is that blacked out word "Aurora," for example, potentially referring to new types of advanced aircraft? And, if so, does that imply that similar redacted memos refer to the same key words? 

A Tool For Historians And The Public

The Declassification Engine could be an instrument for historians and conspiracy theorists alike. For now, though, it's basically just a set of data-analysis tools developed by researchers at Columbia University.

One finds correlations between specific words and often-classified memos, for example. Another was designed to help train the system to pick up on differences between redacted documents, and what was revealed years later when the government declassified them for public eyes. Eventually, they'll form a more cohesive whole, the Engine's creators say.

To take the next steps, the Engine's founders are asking for help. Last week, historians, journalists, legal scholars, statisticians, and computer scientists met at Columbia University to formally launch the Engine — and to ask for money. The Declassification Engine hopes to raise $50,000 to fund the project, and its founders have only raised a few hundred dollars at present.

Matthew Connelly, a historian at Columbia and one of the creators of the Declassification Engine, explained that the group is consciously trying to put the Declassification Engine on the "white hat" side of the fence — the opposite side, in other words, from organizations like Wikileaks.

The Engine's source material consists of documents that have already been declassified and released by the government for public scrutiny. Furthermore, its users aren't "cracking" redactions; they're simply making guesses. What they hope are good guesses, but guesses nevertheless.

How The Engine Revved Up

Declassification straddles a long-standing fault line in American politics, as Marc Trachtenberg, a professor of political science at UCLA explains:

There is thus a built-in conflict between the consumer and the supplier of historical evidence: we historians want to see the 'dirt,' but those responsible for the release of documents want to make sure that the material released does not damage the political interests they are responsible for protecting.

A redacted memo, made public by the Freedom of Information Act. (Source: http://www.foia.cia.gov/)

Declassified documents are often a tool to better understand our own history. But getting at that understanding sometimes requires teasing out decades-old data.

One of the first things the team did last year was to analyze which keywords were most closely associated with federal decisions to withhold documents among 1.4 million State Department cables. They then created a tool to analyze diplomatic activity over time depending on which terms were used, and the likelihood that a cable that included a specific term would still be classified.

That analysis revealed that 1970s cables that contained the word "Boulder" or phrase "Operation Boulder" were much, much more likely to be withheld, Connelly said. As it turned out, Project Boulder was President Nixon's plan, hatched following the hostage crisis at the Munich Olympics, to increase FBI scrutiny of Arabs entering the United States. In other words, 1970s-style ethnic profiling.

In this case, Connelly said, the archive of scanned documents could have served as a historical context when people began discussing the treatment of Arab-Americans thirty years later, after Sept. 11. But without the digital archive of source documents, that context wasn't readily available.

"The reason that these historians have never even heard of it is because the vast majority of the documents have been withheld, in the archives," Connelly said. "Without those documents, we can't even begin to try and derive some of these lessons."

The government originally held back the majority of memos that contained the word "Boulder". (Source: Matthew Connelly)

Is It Legal?

Given the political climate surrounding security in the decade-plus since September 11, the Declassification Engine's creators said last week that they were somewhat nervous that the U.S. government might try to clamp down on it. (The creators, naturally, believe that it's perfectly legal.) Connelly, however, said that the discussion during Friday's conference gave him reason to believe that the Engine's creators aren't likely to face any investigation from law enforcement agencies. 

Nevertheless, on Friday, the FAQ portion of the site was modified to eliminate all references to the project's legality, including that the group sought input from the State Department and the National Archives to better understand the declassification process.

"In some cases, we are using statistical methods to predict what is still classified," the Declassification Engine's FAQ said Thursday night.

How The Tools Work

Connelly gave ReadWrite an early glimpse of one component of the Engine on Thursday night. That's the Redaction Visualizer, which compares redacted and unredacted documents and highlights the differences. On the surface, this seems pretty obvious. 

Comparing an unredacted and redacted memo. (Source: Declassification-engine.org)

But the Visualizer is also the basic equivalent of your math homework: the redacted document provides the problem to solve, and the unredacted document is the "answer". This supervised data will  "teach the computer to teach itself about what's in the redaction," Connelly said.

The text that the Redaction Visualizer pulls out. (Source: Declassification-engine.org)

The real work for the Engine, though, lies in deciphering the redactions themselves. And the biggest arrow in its quiver is context. In total, the Engine uses 117,509 documents from the DDRS, with the most from the Eisenhower and Johnson administrations.

The text of the documents themselves are just one part of the puzzle. But there's a surprising amount  of unredacted metadata attached to each as well: the date, the author, the subject, who classified it, when it was declassified — 68 fields in all, Connelly said. All can be used as clues to make guesses as to what the redacted content contains. Connelly admits that he's not even clear on how well the Engine could work, once it's up and running.

What the Declassification Engine hopes to do for each redaction is generate a "word cloud" of the words that are statistically likely to be hidden by the redaction. Granted, this is a lot easier to do with a short series of letters, such as a name or date. Still, any guesses could be used to tease out further possibilities, and cross-correlated with other, similar documents to make further guesses.

Eventually, the Declassification Engine could become a Web site, where users could upload their own declassified documents, run them against the tools, and also add their own insights. "It would create a virtuous circle, and [users] would be able to make more and more powerful and accurate predictions," Connelly said.

Obama Turbocharges The Engine

The Declassification Engine received an unexpected boon from the Obama Administration on the eve of its launch: an executive order making machine-readable government documents the law of the land.

"Government information shall be managed as an asset throughout its life cycle to promote interoperability and openness, and, wherever possible and legally permissible, to ensure that data are released to the public in ways that make the data easy to find, accessible, and usable," President Obama wrote. "In making this the new default state, executive departments and agencies shall ensure that they safeguard individual privacy, confidentiality, and national security."

The order could remove the need to optically scan some government documents, allowing the Engine to more quickly process bunches of files. It remains to be seen how executive agencies will protect their electronic documents, however. 

But, as Connelly noted, the order begs the question: if machines are now allowed to read government documents, shouldn't they be allowed to guess what they're hiding?

All the computers on the International Space Station that used to run Windows XP now run Linux, reports Extreme Tech. The reason: Microsoft's OS just wasn't "stable and reliable" enough, according to the United Space Alliance, the spaceflight operations company that manages the hardware onboard the ISS in conjunction with NASA.

Image courtesy of NASA. 

The proliferation of mobile devices has created a firestorm of demand for Application Programming Interfaces (API) to act as data gateways between devices and services. But fire can also be a destructive force, and mis-managed APIs can hurt application performance, alienate developers and even lead to costly and damaging data breaches.

API Security Is Critical

Among other things, APIs serve as gateways to Web-based services like Twitter or Facebook. They are the specifications that let developers build applications that communicate directly with those services. You can think of APIs as doors; they let data in and out of a Web service. Just like physical doors, leaving APIs open can let anyone wander in, for whatever purpose.  

APIs are only as secure as they are written to be, explained Alistair Farquharson, chief technology officer for API-management vendor SOA Software. Smart developers make sure their APIs are open only for those people who have the authorized key.

What Problems Can APIs Cause?

The threat assessment for an API that isn't locked down isn't a pretty thing. Insecure APIs can fold under the artificial pressures of distributed denial of service (DDOS) attacks (which attempt to overwhelm a site or service with spurious requests in order to block legitimate access) , blocking the door through which data from a Web service is supposed to flow - perhaps bringing down the entire site. SQL script injections (which attempt to insert malicious code into a database), Farquharson added, could be used to re-route or copy data to outside servers operated by people who have no business looking at your data or your customers' information.

Because APIs enable very deep leveraging of a web service's features, they can be misused by hackers to spoof services, or even pretend to be entire websites, as web designer Feross Aboukhadijeh detailed last Autumn, when he discovered how the HTML5 Fullscreen API could be abused to appear like any legitimate site, such as a banking transaction web site. Aboukhadijeh works through how the fake web site could be created and fool many unsuspecting users, even down to a citation of a study on "change blindness," a psychological event where people can miss obvious changes.

And then there are the less subtle attacks, such as the 2008 security breach that took advantage of a bad Myspace-Yahoo services API and ended up gaining access to celebrity photos that were supposed to be privately stored.

These are the obvious malicious outcomes of APIs that aren't secured properly. But hacked APIs can also create perceptions of poor quality of service, which could erode customer confidence in a Web service.

The importance of getting APIs under control can't be overemphasized, contended identity-management vendor Xceedium's VP of Product Management, John Suit. "If the web interface is the front door to a company," Suit said, "then the API is the side door." And any door that lets in the wrong person - or the wrong code - can result in the same disastrous results.

Building A Better API Lock

Locking down APIs can tricky business. In these early days of the API boom, there are many different API standards being used by vendors to create the APIs through which applications will leverage Web services. Complicating that is the fact that there are a lot of different security standards, too.

This is a rich recipe for problems, since an effective API management system must allow authorized developers in to use the API, but not let anyone gain so much access they can subvert the API or use it as a doorway to the host service's internal data. Oh, and add to that mix the problem you have if APIs have to reside in a public cloud environment, outside your firewall.

Most security experts recommend using some sort of the strong authentication process in place when working with APIs. You need to make sure that the absolute correct person is accessing the API.

SOASoft's approach is a just-launched API Gateway virtual appliance that uses an OAuth server to work with many different existing security protocols. Playing to its strengths, Xceedium uses role-based identity systems to not only make sure the right person is connecting to the API, but that person should be accessing that API in the first place.

Things To Do Right Now

Even if you don't want to implement a formal identity and security management system for APIs, there are steps to take right now that will at least help mitigate potential problems.

If you want to prevent SQL injection attacks, then by all means sanitize the inputs in the API that connect to your internal databases. This will reduce the risk of a successful attack of this kind: 

API developers should also make sure that everything is transmitted through the Secure Socket Layer (SSL) - encrypted and transmitted by HTTPS - so that information like usernames and passwords are not captured in-process and then used to gain access to users' accounts or worse, the host organization's account. 

APIs are becoming increasingly important as so many new devices on the Internet generate and consume data via an ever-expanding list of Web services. While essential, those APIs also creating tempting targets for hackers. The need to lock down this growing vulnerability has never been a higher priority.

Lead image courtesy of Shutterstock, comic courtesy of XKCD.

The developer-focused social network App.net has released a new iOS app dubbed Passport. Founder Dalton Caldwell writes that the app allows users to establish an App.net account, find and follow other users, and discover and download other apps for App.net.

The Passport app does not, however, include posting or messaging capabilities, a deliberate choice intended to push users toward other apps developed for the network. In addition, the app provides new tools for developers:

An additional benefit of the Passport app for 3rd-party developers is a new Authentication SDK which makes it easy to seamlessly integrate App.net login/signup functionality into any app.

Worried about your longevity as a worker in the fast-moving tech industry? What you need is some inspiration from John Sloan.

Who's John Sloan? He's the man pictured in a photo I used in a recent post on 10 Technology Skills That Will No Longer Help You Get A Job. (See that photo below - or on the iPad in the photo above.) While Sloan may look like a symbol of outdated technology in the older photo, he's actually the polar opposite. As, in fact, the newer photo of him above should lead you to believe.

Sloan, aka Chip Overclock, has not only participated in the many amazing, globe-spanning, nano-shrinking changes in computer tech over the past four decades, he has stayed current with the changes - and kept himself gainfully employed - by taking full responsibility for his own career and professional development.

Pictures Tell The Story

The picture below shows Sloan at Wright State University, Ohio, circa 1976. He would soon go on to earn his B.S. in computer science, and later his master's degree. He's seated next to an IBM System/360 Model 65.

Sloan, now 56, lives in Denver. Several of his friends saw my story and noticed the photo, and forwarded it to him, which prompted him to contact me. Sloan describes his current career as a "freelance product developer specializing in real-time and highly concurrent systems." The photo at the top of this post shows Sloan next to his Mac Mini with Cinema Display. That's a first-generation iPad he's holding - displaying the original picture, no less.

Why John Sloan's Story Matters

Talking to John Sloan made it clear that long-term survival in the tech industry was about much more than just mastering a specific set of skills. Instead, it's all about taking personal responsibility for learning and adapting over the years and decades:

ReadWrite: Getting a computer science degree in 1976 was an awfully forward-thinking move.

John Sloan: It was the closest I could get to living in the kind of science fictional universe that I was reading about and watching on television. I still remember today watching the very first episode of the original Star Trek.

ReadWrite: Are you currently employed?  

John Sloan: I'm a self-employed, offering consulting and contracting through my one-man company, Digital Aggregates, and have been since 2006.

ReadWrite: How do you stay connected to all the changes in the computer industry?

John Sloan: I spend almost all my time (when not working with clients) on professional development. I read, I attend conferences, I learn new skills. This is the kind of professional development that companies simply no longer offer anymore to their regular employees. My company exists not just to service my clients, but to keep me current and employable.

Favorite Tech And Tools

ReadWrite: What technologies have you worked on over the years?

John Sloan: I've had a lot of career success, almost all in the systems area, much of it working low in the software stack, close to bare metal. I've worked on IBM mainframes, PDP-11 minicomputers. Cray supercomputers [all the way] to huge distributed Linux systems. My current gig is developing a tiny PBX with Iridium transceivers that will allow flyers in business jets to make phone calls from anywhere in the world.

John Sloan: My iPhone 5. I have no idea how I'd live without it.

ReadWrite: One of the big tech shifts has been the move to open source. How have you tackled this change?

John Sloan: Open source has been very good to me. For several years now a lot of my income has come from hacking open source software ranging from various portions of the Apache software stack written in Java to the Linux kernel and various portions of the GNU software stack in C.

The economics of open source is the most interesting part about it. Back in the mainframe days, you bought the hardware, and got the software and support for free. Now the hardware is almost free, the software is mostly free, and the support is how a lot of companies book revenue.  

ReadWrite: What about the shift from desktop to mobile?

John Sloan: Every time I pick up my iPhone 5 or my iPad, I feel like I'm in a science fiction movie. Same goes for the Android mobiles. I also have a Samsung Galaxy tablet. It's astounding.

Tech Advice For Young And Old

ReadWrite: Do you have any advice for workers who have been in the industry a long time?

John Sloan: Do not trust your career and professional development to your employer. You absolutely must take charge of this yourself.

ReadWrite: What about advice for those just starting out?

John Sloan: No matter what technologies is being taught when a freshman enters university, they will almost certainly not be the ones being taught when that senior graduates. And whatever technologies that student learns will not be what he ends up needing expertise in when he enters the workforce. Continuous, life-long learning isn't a buzzword, it's a requirement.

People who grasp specific technologies but can't quickly learn new ones on their own are the ones who are going to be laid off or whose jobs are going to be outsourced.

ReadWrite: Anything else you want to add?

John Sloan: Hardly a day goes by in which my wife of nearly 30 years and I don't remark on how lucky we've been. Just the other day one of my friends and former Bell Labs colleagues remarked that she was surprised that she still got paid good money to do what she loves to do. I feel the same way.

Lead image courtesy of Flickr.

The next killer app just might be developed by a girl still in high school. 

Meet Kira Becker, Emily Moschella, Tara Abrishami and Anna Venetianer. Not one of them is older than 16, but they’re already accomplished programmers. 

The four have spent the past five months developing Navi Car. Since they attend Thomas Jefferson High School for Science and Technology, a magnet school that attracts gifted students from all over the Washington, DC, area, their commutes are often lengthy. The girls all have active after-school lives, including tennis, track & field and theater, but it’s not always easy to get where they need to be. 

So the girls decided to solve their commuting problem by building an Android app. Since January, the four friends have spent weekends and afternoons making their app a reality with the help of a free programming tool, MIT App Inventor. 

Building Apps To Solve Problems

Not everyone feels adept enough to build an app to solve his or her problems. But for the next generation of programmers, it’s second nature. 

“Technology is becoming more and more accessible. I definitely think people will be making their own apps in the future for exactly what they need them for,” said Venetianer. 

Encouraged by a teacher, the girls were spurred to enter their app in a programming contest specifically for high school girls, the Technovation Challenge. Under the name Team Round of APPlause, they’ve been selected as one of the top ten global finalists. On Thursday, they visited Twitter HQ in San Francisco to have their app judged. 

Although the very existence of a programming contest just for teenage female participants reveals the severity of the gender gap in computer science, the girls said they never felt like they were doing anything groundbreaking. 

Girls Coding: Not Unusual?

“Being in the community that we are in, everyone is so supportive. there are so many other girls [at Thomas Jefferson] interested in computer science and tech in general,” said Abrishami. “I guess a lot of people are impressed and proud of us, but nobody thinks it's unusual.”

As sophomores in high school, none of the girls have made a decision about whether or not they want to pursue computer science careers. But if app building appears as accessible to others of their generation as it does to them, the future of programming looks very bright.

Update: Want to know what happend to the engineer in the 1976 photo above? Click here to find out how he he managed to stay relevant for almost 40 years: How To Thrive In The Tech Industry For Decades.

If you want to know the most in-demand tech skills, that info is readily available. Want to learn the programming skills most coveted by employers? Done. But what are the skills and specialties that no one wants any more? What core competencies raise red flags instead of call backs? 

(See also the Top 7 Most In Demand Tech Skills For 2013 and 15 Programming Skills Most Coveted By Employers.)

A survey of 1,100 tech-hiring professionals by Dice, a job firm for tech professionals, offers some insight. Combining the Dice survey and other research, including an off-the-record conversation with an engineering VP who participates in hiring decisions, here are some of the outdated tech skills and withering technologies to be wary of putting on your resume:  

1. Windows XP Admin/Help Desk

Many IT professionals, from engineers to help desk support workers to system administrators, have significant XP experience. Unfortunately, this may no longer be a useful attribute. Windows XP still holds the #2 spot for desktop operating market share (just behind Windows 7), but its fate is sealed. Microsoft ended XP license sales more than two years ago and plans to cease supporting it in less than a year. 

(See also Microsoft Is Trying To Sell Windows 8 To Enterprises, But Most Want Windows 7 Instead.)

2. Adobe Flash Developer/Designer

Web developers, app developers and designers have long relied on Adobe Flash to create interactive features. Yet Flash's future, particularly on mobile - is quickly drying up. It's now been three years since Steve Jobs created a stir when he posted his Thoughts on Flash memo outlining the reasons why Flash would not be part of Apple's iOS. At the time, Flash was considered so dominant that many analysts wondered if Jobs' decision would crush iPhone sales.

It did not.

Just over a year after the Jobs memo, Adobe announced it would stop developing Flash for mobile devices. Today, Adobe's former CTO, Kevin Lynch, works for Apple. The future belongs to HTML5. Learn, write and build accordingly.

3. Software Support

The transformation of computing from desktop to mobile, and especially the transition of software and services into the cloud is limiting opportunities for traditional/packaged software support. Today, you need to know how to manage software services and software configurations in the cloud. 

(See also Legacy IT Vendors Shoot The Sales Messenger.)

4. SEO Specialist

Google no longer has a Search group. It's now called "Knowledge." That should be a telling warning for all the search engine optimization (SEO) gurus and ninjas looking for work. Expect SEO work to be de-valued going forward. The explosion of smartphones, apps and real-time location information - and especially social media recommendation - is diminishing the importance of search results. Eventually, information may be delivered to us even before we search for it as our integrated, connected systems anticipate our needs.

5. Quality Assurance Specialist and Managers

Hiring professionals in the Dice survey placed Quality Assurance (QA) on the "low priority" side of the ledger. Do not expect this to change. These days, the tech industry seems to be following Google's lead and turning everyone into beta testers. Users are the ultimate quality assurance staff - and they don't get paid!

6. - 9. Mainframes, Voice Telephony, PC Support, COBOL

According to a recent story in the Austin Post, tech recruiters "recommended (that) a 40-year-old still working in COBOL reevaluate why they're a coder." Pretty harsh. But the fact is, technology continues to move forward with no time spared for sentiment.

If you are gainfully employed as a PC repair tech, a COBOL coder, or are working on any of several older technologies, such as voice telephony or as a PBX technician, say, good for you. But don't count on keeping that job for the long-term, or being able to find another one like it. 

10. Something That Seems Secure Today

The TIOBE Programming Community Index lists C, Java, C++ and Objective-C as the programming skills most in demand right now. But here's the thing. In 2009, Objective-C was barely in use. The rapid success of the iPhone and iPad vaulted the language's popularity. Now, however, just over three years later, its popularity is already stabilizing.

In today's superheated technology environment, even the most popular, most secure seeming technology skills can suddenly become obsolete. That's just the way it is. No matter how in-demand your current skill set, you can never rest on your resume. 

Learning Is The Key

Will highlighting the wrong skill set to a recruiter brand you as out of touch - or too expensive to hire? Perhaps. But don't expect anyone to tell you that's what going on. More likely, they may just won't return your call, or let your resume vanish into the ether. (There will probably always be a few legacy jobs in all these areas, but that's about it.)

The only solution is to keep learning - and keep showing that you can learn. While the pace of skills disruption may well be increasing, learning new skills has never been easier. That includes formal schooling as well as free and low-cost resources like Khan Academy and CodeAcademy, for example. 

Here's the bottom line: Since so much technology is fairly new to everyone, why should a company invest in experienced candidates - rather than someone just starting out? Writing for The Wall Street Journal, business professor and entrepreneur Vivek Wadhwa, was brutally direct:

It may be wrong, but look at this from the point of view of the employer. Why would any company pay a computer programmer with out-of-date skills a salary of say $150,000, when it can hire a fresh graduate — who has no skills — for around $60,000? Even if it spends a month training the younger worker, the company is still far ahead. 

(See also Vivek Wadwha in How A $20 Tablet Will Change The World [Video].)

It's not just about the money, of course. To justify any salary, it's not only about what you know - now - but what you can learn going forward. The key to a long career in Silicon Valley, or anywhere in the tech world, is showing that you can learn and adapt - and master - constant change.

Good luck!

Lead image courtesy of Flickr.

Programming has always been a bit of a boy’s club. Now four startups are turning the tables. 

As the coding education bubble swells, there’s room for some companies to target more specific audiences, including women exclusively. Fifty percent of the female population isn’t exactly a niche group, but it’s not a frequently targeted market in the technology industry, either. 

Even in the year 2013, we seem stuck on the stereotype of the typical “brogrammer.” Women and girls have always been some of technology’s most influential users (remember who fueled the rapid rise of Pinterest, anyone?) but they’re woefully underrepresented in professional tech jobs.

Directed at women and girls of varying ages, each school on the list has a secondary motive of expanding the coding population beyond the stereotypical “brogrammer.” Check them out:

Girl Develop It

Readwrite first covered this startup back in 2010 when it was called Girl Develop IT. (See what they did there?) Two years later, it’s still going strong. This woman-only school now has chapters in 16 cities in America, Canada and Australia. 

Founder Sara Chipps thinks the best way to shrink the tech job gender gap is to give women the resources to become “rockstar programmers” in a space where they feel comfortable. Girl Develop It classes are casual and low cost forays into coding. 

Black Girls Code 

Only one percent of technology startups are founded by African Americans, much less African American women. Founder Kimberly Bryant often finds herself to be the only black woman at tech events, and didn’t want the same life for her tech-savvy teenage daughter, Kai. So she founded a school where young black girls could learn to code surrounded by their peers. 

Black Girls Code targets girls of color aged seven to 17. Originally founded in San Francisco last July, this nonprofit now offers courses in seven American cities thanks to the help of several hundred volunteers. 

Girls Who Code 

Part of the gender gap in programming is a mental one. Reshma Saujani founded Girls Who Code not just to teach girls 13 to 17 how to code, but to convince them that it’s possible.

“At age 13 or 14 there is something that happens that makes girls think coding or engineering is not for them,” she told ReadWrite last year. “Part of our mission is pushing girls to go into these technical fields and overcome their aversion to risk.”

The startup is about to begin its second summer program, this year available in five cities. 

Girls Learning Code/Ladies Learning Code

Whether an aspiring female programmer is nine or 49, this Toronto-based nonprofit has a program for her. Ladies Learning Code invites women (and the occasional man) to collaborate on learning technical skills. All courses are currently at the introductory level in a variety of programming languages. 

The more recently launched Girls Learning Code program is, in its own words, “less about 'code' and more about changing the world.” Girls from nine to 13 are encouraged to explore programming as a means for exploring their creativity and get comfortable with computers.

Thanks to its wide age range, perhaps the nonprofit’s most unique program is a mother-daughter hack day. How’s that for a tech-forward Mother’s Day activity?

Photo courtesy of Girls Who Code

Security researchers recently found gaping vulnerabilities in a wide variety of critical business and industrial equipment. It turns out that weak or absent passwords made it easy to break into more than 100,000 terminal servers used to provide their Internet connections. Fixing the problem is simple. Change the credentials dramatically reduces the risk. But for many companies, actually solving the problem is nearly impossible.

Vulnerable, But Hidden

The threats discovered by security firm Rapid7 exemplify the difficulties organizations face in plugging even known holes in critical gear. In this case, the affected systems include industrial control equipment, traffic-signal monitors, fuel pumps, retail point-of-sale terminals and building automation equipment such as alarms and heating and ventilation (HVAC) systems.

Rapid7 found more than 114,000 unprotected terminal servers, mostly from Digi International or Lantronix, that a hacker could use to take control of the underlying systems. Finding the serial ports on the server requires the use of a scanning tool, such as Nmap. Once an active port is found, a command-line program similar to what those used in 1980s vintage home computers is all that's needed to access a control panel or menu or capture data.

Fortunately, while tech-savvy saboteurs or terrorists would have no difficulty gaining access to the equipment, they most likely would not know who owns it or where it is located. Without that information, the find would not be very useful. "There's no telling who they are going to hurt, if they don't know where the device is," explained HD Moore, chief research officer for Rapid7.

How Security Gets Missed

Nevertheless, any hole that can provide access to critical equipment is worth plugging, but it's not likely to happen in many of these cases. Often, companies do not even know the terminal server exists, much less that it needs security updates.

How is that possible? Well, picture a vendor working with the facilities crew installing an HVAC system that uses a terminal server so the equipment can be monitored from a remote location. No one knows the server exists, and no one cares, as long as everything works. "A lot of times IT is not even aware of these systems," said Matthew Neely, director of research at risk management company SecureState.

Vendor marketing can also exacerbate the problem. Equipment is often sold as being "secured," when in fact it is only "capable of being secured." That means the buyer still has to add the technology or turn on and configure the security features.

This can get missed if the installers assume the equipment is "plug and play," said Joe Weiss, a security consultant for Applied Control Solutions. "It's like getting a toy for Christmas and you pull it out of the box expecting it to run, because the box doesn't tell you it needs two AA batteries," Weiss added.

Terminal servers, also called serial port servers, often get missed by electric utility companies because they are not covered under federal cybersecurity requirements. So the devices never make it on the utility's compliance checklist. "They don't even have to check these out to find out if they are or not secure," Weiss said.

This bizarre situation demonstrates that ensuring the security of critical equipment is never a matter of technology alone. True security requires people to pay attention, not just sweep everything under the rug.

Image courtesy of ShutterStock.

Say you're interested in learning to code. Should you go back to school and pick up a formal diploma? Or just teach yourself (perhaps with some help from the Internet) in your spare time at home?

Catalin Zorzini, the founder of Web design resource site Inspired Mag, was wondering just that, so he built an infographic on the subject. “Some readers are confused by the relevance of attending university in a time where technology information is not locked within the university walls anymore,” he told me.

(See also: There's A Boom In Teaching People To Code)

After two weeks worth of extensive research, however, Zorzini said it’s not about one type of education being superior. “The challenge is to be able to match the right type of course with the right student mindset,” he said.

Zorzini’s finished infographic, based on information from editorials, universities curriculums, reviews, and even the opinions of practicing Web designers, won’t tell you which method is “best.” But it may help you figure out which method would be best for you. Check it out below:

Photo by Joseph McKinley

As programming tools become increasingly accessible, it’s not the actual building of a mobile app that’s difficult. It’s the time it takes — and the risk nobody will ever use it. Studies estimates that 26% of mobile apps are used just once, and more than 60% never get downloaded at all.

We are well into the age of the disposable mobile app. Now, according to Raw Engineering, the makers of Built.io, we have the fast, easy to use app-development technology to match. 

Temporary, Disposable Apps

Today, many businesses create apps for a variety of occasions, including one-time events like conferences and product announcements. But for most businesses, building these apps is a process that can take several months. At Demo Mobile 2013, Raw Engineering CEO Neha Sampat showcased an app her team built in a week. 

“The life of an app used by enterprises is sometimes as short as a month,” said Sampat. “If it takes you three to four months to build an app you’re only going to use for a month leading up to an event or a conference or an announcement, there’s no [return on investment] there.” 

Leveraging Built.io, Sampat said, app development can be almost “plug and play.”

“We provide the back end, the building blocks, the basics of the app ready to go - and they can spend their time working on user experience and the app itself.”

Crowded Market For App Development Tools

Decluttering the back end of app development is a mission on everybody’s mind. Built.io joins a crowded market, including services like Parse (just acquired by Facebook), Kinvey and Cocoafish. But here’s what makes Built.io different, for better or for worse: anybody can use it.

(See also The Rise Of Mobile Cloud Services: BaaS Startups Grow Up.)

Creating new apps requires a developer’s assistance. But "once the app is built and available, [employees] can log into the [content management system] and upload additional photos, press releases, anything they need to do to update the app without running to their developer or IT department,” Sampat says. 

The easy-to-use, what-you-see-is-what-you-get visual design is intended to make app upkeep less of a headache for developers. But developers have also historically been gatekeepers. When everyone and everyone at a company can make updates to the company app, what’s to keep the company app from becoming a huge, cluttered mess?

Developers In Charge

To avoid that, Built.io keeps developers in charge. A Built.io feature lets them assign roles and privileges to specific users. For a conference app, for example, the developer might give the organizer permission to update event names and times, but not to alter the structure of an app. 

Built.io has the potential to make developing a company app so fast and so easy (the beta is free) that everybody in the office may want to create apps for every purpose they can think of. The question yet to be answered is whether non-developers will use their newfound powers for good - or end up helping to churn out useless apps on a weekly basis, adding to the existing glut of unwanted and unused mobile apps.

Photo and screenshot via Raw Engineering

And you thought being a software engineer was all about dreaming up clever algorithms or amazing graphics routines and then instantiating them in elegant, tightly written code. Shows what you know.

It turns out, at least according to a survey conducted by software delivery service Electric Cloud, that developers spend almost 20% of their time... waiting. Waiting for their code to compile (that is, for it to be translated from a programming language like Python or C into a binary machine language computers can execute). Waiting for test routines to finish running. Waiting for that junior developer to get back with the Diet Coke and Funyons.

(See also: Learning To Code: Get A Degree, Or Just Teach Yourself At Home? [Infographic])

You get the idea. According to the survey, software engineers spend as much time waiting as they do brainstorming and collaborating. Check it out (click on each graphic for a larger version):

Of course, waiting can take many forms. Some programmers doubtless use the time to plot our their next project or bug fix. Others may have, well, other pastimes. (As in this iconic XKCD comic, for instance.) In any event, the sheer amount of time devoted to the waiting game blew the surveyors away. 

"It was definitely surprising," said Ashish Kuthiala, Electric Cloud’s director of marketing. "When I was a software engineer, I remember losing time to meetings when I’d rather be coding. But we didn’t realize how much time engineers lose waiting for tests and builds to complete."

Electric Cloud conducted its survey last month after hearing clients — a group which includes Intuit, Samsung and GE — complain their engineers weren’t working as quickly as they’d like. 

"Software engineers are our clients' most expensive resources, so they're always concerned about whether they're being as productive as they can be,” Kuthiala said. Spoken like a true pointy-headed boss, you might say.

Electric Cloud circulated the survey to LinkedIn groups and forums engineers frequent, offering a Kindle raffle prize as an incentive. So far, it's received nearly 1,200 responses. Survey participants had the option to remain anonymous or disclose their company names.

"Every time we conduct the survey, the results continue to map on top of each other," Kuthiala said. “It doesn’t just show how the majority of engineers spend their time, it can be used as a benchmark to see how your company’s engineers are doing compared to the average."

Is there any way to shorten those waits, or even avoid them altogether? Not really. Unsurprisingly, Electric Cloud offers a service it says can help by automating the cycle of building, testing and deploying code. Some open-source software claims to do something similar. And then there's the time-honored, if not-necessarily-reliable, option of just throwing as much hardware as possible at the problem.

And yet as long as there are compile delays and testing latencies, engineers will always have an excuse when they're slacking off.

Let's hear it, coders. How does your work week break down compared to these survey results?

Photo by Flickr user Phil Heaberlin, CC 2.0

Updated at 11:49 AM on April 25: Electric Cloud's client list has been updated based on new information from the company.

A technology born of the Web and accelerated by mobile is now blossoming inside businesses. Ignored for years, application programming interfaces—a key layer of connectivity between disparate software—are undergoing a renaissance.

The trickiness of managing these connections, and their importance to the way businesses run their operations today, explains why we see vendors like Intel buying Mashery. Or CA Technologies snapping up Layer 7 Technologies. Or MuleSoft picking up ProgrammableWeb. Or, this morning, a startup contender, 3scale, raising $4 million from investors.

And that's just in the last seven days.

Of course, this raises the question: what the heck is an application programming interface?

First, The APIs

In the simplest terms, an application programming interface, or API, is a set of requirements that enables one application to talk to another application.

On your desktop, an API is what lets some applications talk to others (like Word to Excel and vice versa), or access features of the operating system. Such APIs are familiar ground to any programmer who has built an application that needs to share features or data directly.

This is the API with which I am familiar: steady sets of code and requirements that lived on the operating system. But there's a whole other class of APIs, built for Web services, that has kicked open the field of API management.

Web APIs are analogous to their older counterparts, but they serve as gateways to Web-based services, like Twitter or Facebook or Foursquare or Amazon. They are what enables developers to build applications to communicate directly with those services.

If you have a third-party app that connects to, say, Twitter, that app communicates with Twitter's API to handle the actual connection. You, as the user, never see this API. As far as you are concerned, the whole thing is seamless. You post a tweet in the app and it shows up in the Twitter feed. But it's the API that handles the job.

It is easy to think of APIs in this context as doors; they let data in and out of a Web service. But they are rarely indiscriminate doors. Like any door, they only swing in a certain way. And they are typically open for only the people who have keys to the lock. They have rules.

And rules have to managed.

Here Come The Managers

It turns out, explained Ed Anuff, a vice president at API management vendor Apigee, there are actually a lot of things that need to be managed about Web service APIs.

There's the sign-up process for developers who express interest in using an API. There's the documentation for the API, so they can write code that accesses it. There are credentials to be issued to both developers and users—these are all just part of the scope of information that has to be managed when a service releases an API for developers.

"All of that stuff is part of what an API management tool does," Anuff said.

A critical function of API management tools is handing out the keys that let authorized developers unlock the door to a Web service's data and functionality. Some APIs charge for access; API management tools handle billing. Sometimes there are limitations on access; those must be enforced.

API management began as a way for popular consumer Web services to open up to the creativity of independent developers. But what fueled the rise of API management as a cottage industry was enterprise IT managers who saw the success these household Web names were having with their APIs and who wanted to adapt the same model for their internal infrastructure.

"Lots more companies looked at these Web services and saw things they needed," Anuff said. "Internal APIs didn't have this self-service stuff."

What really kicked the industry in the pants, however, was the tidal wave of mobile computing. Rather than building two separate versions of software for a desktop website and a mobile app, it's far more efficient to build an API for the underlying service that holds user data and business logic, and then build desktop and Web versions of software that talk to that same API.

Add up all the different mobile platforms out there—iPhone, Android, Windows Phone, and so on—and an API rapidly becomes the only sensible architectural approach. Suddenly enterprise developers needed much better API management to handle all of the apps they wanted to build for their own employees on a variety of platforms.

It's All About The Data

Anuff gave two big reasons why enterprises are seeking API management tools.

The first was operational. If a developer produced a poorly written app that made a burst of requests to an API, one right after the other, for instance, an API management tool would enable the IT staff to throttle the requests hitting the company's Web service to something approaching a sane level until the app could be fixed.

The second example is very likely the reason why there's been so much interest in this sector of late.

Recall that when an API is in use to connect to a service, then all of the data shared by the third-party app and the service passes through the API and, therefore, through the API management tool. This means that API management tools can be one-stop shops for rich and valuable data.

Larger vendors who want to keep their skin in the big-data game are going to be very interested in startups in the API management space. The analytics API management tools can provide for the requests they handle are a rich gold mine of information, and a new source of data is bound to attract attention.

Which explains a lot of the hubbub.

The Machine-to-Machine Future

Today, the APIs we think about most often - like Twitter's and Facebook's - typically handle requests generated by people clicking on a website or swiping and tapping on an app. But another, far more interesting potential for APIs lies in processing requests generated by machines - a market that could hit $18 billion in spending by 2014.

Think of the smart, Internet-connected energy meters being adding to homes. Or diagnostic sensors in your car that report back to the manufacturer when there are signs of an incipient engine failure. Or systems that detect atypical network traffic and reroute it on the fly to avoid slowdowns or outages. These all need defined rules for how one machine talks to another. And those rules are found in - you guessed it - APIs. APIs that need to be managed.

That's the real growth market for APIs. And it suggests that what we've seen in the past week is only the first glimmer of a vein of gold that smart people will mine for decades to come.

Image courtesy of Shutterstock.

Preschool and kindergarten are recommended times for kids to learn a new language, while they’re still in the process of learning their first one. So Grechen Huebner and her cofounder, Jon Mattingly, created an app that teaches kids to program - before they’ve even learned how to read.

The idea behind the iPad app, Kodable, is just that simple: create an app to make programming a child’s second language as early as possible in the child’s life. Kodable is designed for children between the ages of five and seven, but Huebner said it’s been tested and enjoyed by kids as young as three. 

“One of my favorite moments was when this three-year-old boy was playing it and literally screaming, he was so excited,” she said. “He already got the concept. He just needed a parent to help him drag and drop.

“I had gone to a baby shower where the mother got this software called ‘Your Baby Can Read,’ so it started as a joke - oh, what if we created, ‘Your Baby Can Code’? Then we started researching and figuring out that the best time for kids to learn is when they’re really young and still developing their cognitive abilities,” Huebner added.

Kodable has no written instructions. As soon as kids learn to drag and drop on an iPad, around age four or five, they’re ready to play. Huebner believes that they can still enjoy the app before that, with the assistance of a parent. With a series of directional arrow commands, kids lead cute, pastel balls of fuzz through Kodable’s 90 levels. The first 30 levels are free; each additional set of 30 levels are a $1.99 add-on. 

Each level, designed by Huebner and programmed by Mattingly, aims to teach kids something about thinking like a programmer to solve problems. As they navigate through the levels, children utilize functions, conditional statements, if/then statements and loops. 

Huebner and Mattingly launched Kodable in June 2012, having just graduated from the University of Louisville. They created 10 initial levels, which they tested with children from ages 3 to 9 and discussed with early childhood educators. Their current project is working with educators to create a curriculum that works alongside Kodable, so parents can teach their kids programming in a more structured way. 

Teaching kids to program is a huge trend today, but it’ll be at least 15 years before Kodable’s five-year-old audience enters the workforce. Who’s to say that by the time these kids grow up, programming jobs will still hold the status they do now?

“Jobs in software development are increasing at a rate that’s double that of any other industry. There will be jobs. And whether or not kids choose to become programmers when they grow up, understanding technology is still a very important skill,” said Huebner. “Technology is a huge part of our lives and it’s only going to become more a part of our lives. It’s not ever going to go away.”

Until last February, Janine Holsinger had never typed a single line of code. But the Columbus, Ohio, entrepreneur wasn’t going to let that get in the way of her dreams. She signed up for a service called Treehouse, paid the monthly fee of $25, and devoted 8-10 hours a day to learning Ruby on Rails. 

“Within a few days, I was building my own Rails application,” she said. “Within 30 days, I’d launched my company website, NextChapter.”

Holsinger’s experience shows just how empowering and lucrative learning to code can be. But some startups are learning there’s even more to be made in teaching the skill to others. 

Code Breaking Records

Within the last two years, more and more companies have saturated the market with the express purpose of teaching everyone and anyone our generation’s hottest new job skill: programming. Now it’s become a fundraising race to the top of the pile. 

This April, learn-to-code startup Treehouse announced that it raised a “war chest” of new funding. In a Series B round led by Kaplan Ventures, the Portland, Ore., company added another $7 million, for a total of $12.35 million. 

For CEO and founder Ryan Carson, the money couldn’t have come at a better time. Competition between learn-to-code startups is rising, and Carson plans to press his advantage by adding more employees to Treehouse's current 55 workers.

One of Treehouse’s biggest competitors is the omnipresent Codecademy. Founded by 22-year-old Zach Sims, Codecademy has been heralded as the leader of a “movement” in code education. The startup’s most recent Series B funding round, in July 2012, brought the company $10 million. With just nine employees, Codeacademy is just a fraction the size of Treehouse size, but it boasts “millions” of students, including the mayor of New York City.

The newest startup on the playing field is Tynker, launched just last week with $3 million in seed funding. Like many programming apps aimed at young children, Tynker uses a visual programming language designed to get kids comfortable with coding. Even though Tynker doesn’t have a product yet, angel investors like 500 Startups are already comfortable funding it into the millions.

It's Not Just Venture Money, Either

Even learn-to-code startups who aren't looking for venture capital are finding that money is easy to come by. When Code School wanted to crowdfund an iPhone app development course, it turned to Kickstarter and earned triple its $50,000 goal. Meanwhile Girls Who Code, a nonprofit that targets the gender gap in the tech industry, received a quarter-of-a-million Knight Foundation grant last year. 

The startups named above are all less than two years old, but the market’s education giants already know that programming tutorials are a goldmine. Udemy raised $12 million in a December funding round, and tech education oldtimer Lynda raised $103 million this January.

It’s hard to say how long the money will keep flying at this rate. But it's clear the race to dominate coding education is on — and still wide open.

If you want to give your kid every opportunity to succeed, it’s hard to argue with teaching them to code. Some of the wealthiest and most influential people of our time began programming young, and who wouldn’t want that kind of future for our kids?

Yesterday, we reviewed Hopscotch, an iPad app that teaches children the basics of any modern programming language. However, that’s just one of the many options out there. Here are six free tools to get kids excited about code. Whether she’s 5 or 15, and whether she wants to learn Ruby or Java, there’s something here just for her:

Scratch
Age range: 8 and up
Language: Original visual programming language
Platform: Browser-based

With over 3 million uploaded user projects, Scratch is undeniably popular. The visual language and interface was created at MIT Media Labs to get kids coding early, even if they can’t yet understand the complicated syntax that makes up written computer languages. In order to use it, kids just log onto the site and start dragging and dropping sprites and blocks of code. The results look something like early Flash projects.

Since Scratch is a Turing-complete computer language, anything that kids can imagine, they can build.

Alice was designed by researchers at the University of Virginia as a gentle introduction to object-oriented programming. Its namesake, the Lewis Carroll heroine, stresses the researchers’ emphasis on making coding appealing to young girls. In Alice, draggable blocks of text instantly affect 3D sprites in a virtual world. Kids can test programs while that they create them, watching the sprites change in real time as they manipulate the block statements.

This program has the youngest audience of the list. Created by the makers of Hopscotch, this iPad app teaches the basics of programming logic in a way even kindergartners can understand. Kids can use ultra-basic blocks in order to animate Daisy the Dinosaur. Just drag one-word commands like “roll,” “jump,” and “grow,” into the programming space, and press play. Players can see a direct relationship between the commands they assign and the actions Daisy takes.

Two years ago, ReadWrite has reviewed Hackety-Hack as Ruby “for the absolute beginner.” Since then, it’s been recommended as an ideal introduction for teens. With cute graphics and simple explanations, teens can learn Ruby even if they’ve never touched another programming language before. The interface is divided into two screens, an “editor” for inputting commands and testing programs, and a lesson that clarifies the code in plain English. After the tutorial, users create and share basic games and programs.

To the uninitiated, technology can look a lot like magic. Code Monster takes away the complexities of writing JavaScript and leaves just that. It was created by Greg Linden, who wanted to teach his own kids how to code.

This split screen tutorial places JavaScript on the left of the screen and images on the right. When kids alter the variables on the script side, the images transform instantly in response. Under the instruction of a friendly monster sprite, each new lesson brings new colors and shapes to the right side of the screen. Plus, the editor remembers your progress, directing you to the last lesson you completed each time you reopen the program.

Codecademy has been touted as the tutorial to teach anyone to code, even disenfranchised populations, and yes, even preteens. It lacks the cartoony sprites and colorful interface of any of the other kid-targeted tutors on the list, but it’s still friendly and simple to grasp.

Through Codecademy, kids as young as 12 can get started in Python, Ruby, PHP, HTML, or JavaScript, even APIs. The tutorial is also trying to expand its appeal to young beginning programmers with its After-School Programming effort, encouraging students and educators to start a programing club at their schools.

Did we miss a programming tool your kid loves to use? Let us know in the comments.

Image courtesy of Shutterstock