Reading, Bookmarks and Pads

Somewhere between the Zite app, favorites on Twitter and Read It Later is an opportunity. For example, I often discover stuff on my phone using twitter but I want to read it on my tablet or desktop. Why not every time I favorite a tweet it now shows up in Zite on my tablet. This is how bookmarks are suppose to work between synced browsers.

So as a developer I should probably be asking "Should this event, like pressing a button, trigger a sync that would show up on my other devices?"

BTW: Love Zite on my Touchpad.

How to get a mobile phone developer job - Part 4 #learnmobile

I was asked to write up my recommendations for learning mobile. All four parts are listed at the end.  Please leave comments of other favorite blogs or online magazines.

---

There are several recommended online magazines. When you read a good article, remember to use twitter and post to your blog. In no particular order:

smashingmagazine.com - especially appropriate is the coding tab. Also articles tagged with css. Like several other magazines, they are now publishing ebooks, but they will cost a few dollars. 

listapart.com - there are so many articles enjoy exploring. CSS articles are a strength. Also ebooks. 

net.tutsplus.com - good source of tutorials both for free and for a fee. They also sell books. 

dailyjs.com - generally for the advanced javascript user, but enough articles on learning that you should not ignore. 

html5rocks.com - good tutorials about the latest features you can get in a browser. If nothing else, it should give you inspiration for your own apps.

Are you overwhelmed? Everyone is. You don't have to read all of the articles. Find the ones the interest you and written in a style you like. Take your time. And you don't need to know everything. Just do something everyday.

The important thing is to create and contribute. It is easy to gain experience at no cost, have some fun and join the world of mobile developers.

Comments welcomed.

Intro | Part 1 | Part 2 | Part 3 | Part 4

How to get a mobile phone developer job - Part 3 #learnmobile

I was asked to write up my recommendations for learning mobile. This is Part Three. Part One is here and Part Two is here. In this part I give you some ideas for simple mobile apps. Please leave ideas for other simple apps in comments.

---

Next round. You'll have to write some code. To do so you'll need to learn a computer language, storing data and about browser styles. For mobile you need to learn some JavaScript.

eloquentjavascript.net - to this point everything has been fairly easy. Learning JavaScript is the one requirement for any mobile app job. You could buy books or pay for courses, but one of the best books is free: Eloquent JavaScript. And if you use the web version, it is interactive. Highly recommended. (Update: Stackoverflow no longer has other recommendations. This was recommended.)

json - you'll often have to read or store data in your JavaScript apps. Json is the format for data in JavaScript. You should master how to read and create Json. It is fairly simple, but it may take a while to grok it. After you do, you may be struck at the beauty of it. Using json in your early projects is a good way to master it.

css and HTML5 - you'll have to know basic CSS in a mobile job. Few people know CSS very well - you need to know the basics like setting colors. Move on from there to HTML5. 20 sites to help you.

Again, don't be overwhelmed. Just learn what you need to get your weekly mobile app published. You don't need dancing, modern fonts to make your app useful. Getting your first JavaScript Ajax code to read a Json file and display it in your HTML page will be thrilling.

There are lots of different ways to learn how to code. Here are a couple to consider.

codeyear - sign up to get weekly emails to help you learn to code. This is the only service that I have not personally used, but it backed by some high profile organizations. Thousands have signed up.

lifehacker - the learn to code series is short set of articles to teach you the basics. It makes it look less overwhelming than the long books.

jquery - I've recommend jquerymobile without specifically mentioning jquery. It is helpful to learn basic jquery stuff like Ajax and html(), but before learning basic javascript first is required. The jquery website recommend some tutorials.

Do a search if you want to find others. Don't concentrate on mastering JavaScript, CSS, HTML for jQuery. These are just tools to help create that weekly web app.

Just keep at it everyday. Everyday use git. Everyday write some code from a tutorial or your own project using git and github. Everyday blog about what tutorials you read, what you coded and what you learned. Everyday tweet about your blog post or highlight a good tutorial. Some days you may have several blog post and tweets. Everyday.

There is a fourth part about recommend daily reading. 

Intro | Part 1 | Part 2 | Part 3 | Part 4

How to get a mobile phone developer job - Part 2 #learnmobile

I was asked to write up my recommendations for learning mobile. Part One is here. In this part I give you some ideas for simple mobile apps. Please leave ideas for other simple apps in comments.

---

Every week publish a mobile app. This is not impossible especially using jQueryMobile and tutorials. It does not have to be 100% unique. Pick a tutorial. Do the step-by-step coding. Then modify if you want. Push it to github and put it in your public dropbox account. Blog about it. Tweet about it. In no time you'll have a portfolio of apps to link to in your resume.

Besides doing the tutorials, here are some simple mobile apps you can do without any JavaScript coding. Basically any list can become a mobile app.

1. Your mobile resume. Rewrite your resume into jQueryMobile.
2. Learnmobile. Rewrite this post into a mobile app.
3. Your mobile apps. Link to all of your mobile apps in dropbox. Update weekly.
4. Favorite recipes. Make a list of food you make often with pictures or videos.
5. Best articles. Instead of just bookmarking resources you like create a mobile app.

Once you have a little JavaScript under your belt you there are more options.

1. dynamic list - store data in Json, read Json and create list. Convert you mobile apps dynamic.
2. add to list - create a list that can be added to and stored in local storage.
3. todo - perhaps the most common app people try. Keep it simple.
4. rate it - provide a list of items to be rated and resort list after each rating
5. #learnmobile tweets - use the tweeter search api to get the latest tweets with the hashtag.

Your next steps are in Part 3.

How to get a mobile phone developer job - Part 1 #learnmobile

Over lunch I was talking with a friend about how difficult it is for young people to find jobs. After mentioning the hiring I see for mobile development, she asked me to write up my recommendations for learning mobile.  This is Part One.

Like most things, you have to show some experience before getting hired. Here are the steps I recommend you take to start gaining experience.

Meetup.com - Get an account and look for meetups in your area related to mobile. Attend some, listen and say hello. At many of the mobile ones that I attend mobile companies are hiring. In the Washington DC area there are probably a couple mobile related meetups per week. Lots of people go with no experience just hoping to learn. You'll figure out in a month which ones are for you.

chrome - I strongly recommend you start using Chrome as your browser. It is the best desktop browser for developing mobile apps. View source on web pages to learn how designers put together some HTML features. Leave the developer tools enabled to see css and javascript. Try changing some css on a live webpage to learn css better.

Git - You are going to need git on your computer. Every time you start a project you use git to create a repository. A repository gives you version control - a safe way to revert to an old version of your code if you need to. This makes it all the easier to experiment with you code. The easiest way to setup and learn git is on help.github.com (see next).

Github.com - If you are going to be a developer, you'll need a github account and get good at using github. Set up a free account. There are over a millions users and even more repositories. Follow a couple and contribute. The great thing is that you don't always have to contribute code. Even documentation is welcomed. 

Dropbox.com - Set up a free account and set it up on your laptop. You can also set it up on your phone and tablet, though this is optional. Do NOT develop code in your dropbox folder. Instead use git on your local hard drive and github. What you'll be using dropbox for cheap web hosting of your code. Put a file in the public folder  (video) and you'll then be able to access that file from the web. Very handy for testing on phones and tablets or sharing with a friend.

Text editor - If you are coding you'll need a text editor. You can spend lots of money but no need to do that yet. If you want to take the full plunge get the free IDE called Eclipse. But for now, all you probably need is something like NotePad++ for windows. 

HTML - Learn very, very simple HTML. To start all you need to know is how to type in a simple page with a title and a couple of paragraphs. HTML5 will come later. 

jQueryMobile.com - You can write a mobile app in 4 hours using jQueryMobile. Really. It won't very graphic, but few non-games are. All you need is a web browser and a text editor (not Microsoft Word). The quick start guide should be enough, but there are many tutorials on jQueryMobile. When you have finished writing it, post it to github. Then do one a week (see Part 2).

blog - Any blogging service will do. I use blogger.com and posterous.com. Others use wordpress, typepad or tumblr.  Every day - repeat - every day write a short post about what you did to learn mobile apps that day. While not many people may read your blog, you need a place to capture what you are learning and share it with others. Your potential employer will also see that you are serious by working everyday.

twitter.com - You'll need a twitter account. Write up what you are trying to do in the profile. Tweet daily. Point out good tutorials you've found. Highlight good blog posts you've written. Thank people. You'll also find a few people to follow. Use the hashtag #learnmobile so others can follow your tweets - and maybe develop a community of learners.

When you do all of the above, you will start building up some experience. People will know that you are serious about learning how to become a mobile developer. You'll also have your first app published on github. And hopefully, your contribution to another github project was accepted which you now add to your resume.

You should be able to start all of the above within 8 hours. Perhaps 4. And at no cost. You'll be on your way.

Keep at it everyday. Everyday use git. Every day write some code from a tutorial or your own project using git and github. Everyday blog about what tutorials you read, what you coded and what you learned. Everyday tweet about your blog post or highlight a good tutorial. Some days you may have several blog posts and tweets. Everyday.

After you do the above, you are ready for Part 2.

Intro | Part 1 | Part 2 | Part 3 | Part 4

How to get a mobile phone developer job - #learnmobile

Over lunch I was talking with a friend about how difficult it is for young people to find jobs. After mentioning the hiring I see for mobile development, she asked me to write up my recommendations for learning mobile. So I started writing and it became this series of posts that I'll publish this week.

This series is on mobile web apps. Not native iPhone or Android apps. Some call it the HTML5 stack. I think of it as JavaScript, CSS3 and HTML5. There is a great future writing apps this way and then using PhoneGap.

I sincerely welcome comments on this series, especially people that have been recently hired into a mobile job. You may have a different approach that others would like to hear about.

My qualifications to write this series may be considered minimal. I don't hire mobile developers. A couple of my mobile apps are in production but none are consumer hits. I don't write apps for the iPhone or Android apps stores. However, I've probably written nearly 50 mobile web apps in the last several years. I now prototyped many projects using jQuerymobile. My first JavaScript application was published in 1996.

And besides, a friend asked me to write this up. So hopefully it is useful to them and others.


Intro | Part 1 | Part 2 | Part 3 | Part 4

Test Driven API Development Thoughts

This was the basis for my lightning talk at #nodedc on December 14, 2011. It received positive feedback.

---

I wish I was better at Test Driven Development, I guess most developers do to. For me Rails started it, jQuery pushed it, but I still don't do it. But I'm trying. I'm talking build the test, then write the code. I may have a way to do the walk.

I have this idea for TDD for APIs. I want to take the idea of TDD outside the realm of a language or framework. In consuming an API the underlying language does not matter. Therefore, using TDD for developing APIs or developing with APIs should be outside the language or framework.

This project could also be a template for good practices in creating RESTful API. For example, a RESTful API is suppose to be about one resource. While that is good in theory, in practice it often works out differently. So however the design works, it needs flexibility.

There are probably three part to the project: an engine, a reporter and builder. The engine would read a json message, run the tests and report back. The builder would create the json message for the engine. The builder form would allow you to enter a URL/resource and test it. The result would be filled into the expect result field, which could be overwritten. This information could be used for documentation as well.

It could be especially useful for apps that depend on a variety of APIs from different sources. Run the tests regularly to make certain the APIs are still functioning as expected.

Or maybe this already exists? Or maybe this depends on Mocha? Or other existing packages?

Anyway, that is the concept. Thanks to the @nodedc for listening.

 PS One other feature, it should be able to run the same tests against a variety of environments: dev, qa, production, server01, server02, etc.

PSS. Since a RESTful API is like GETting a web page, it probably has broader uses than just APIs.

The GitHub Revolution

We shape our buildings; thereafter they shape us. - Churchill

Once again, Mikeal Rogers has a thoughtful and insightful post called "Apache Considered Harmful." I have no opinion or personal interaction with the Apache Foundation. Rather my focus is on his view of git versus subversion. He calls it "The GitHub Revolution." I could not agree more even though I'm not very active on GitHub.

On GitHub the language is not code, as it is often characterized, it is contribution. GitHub presents a person to person communication system for contributions. Documentation, issues, and of course code, travel between personal repositories. 

The communication medium is the contribution itself. Its value, its merit, its intentions, all laid naked for the world to see. There is no hierarchy or politic embedded in the system. The creator of a project has a clear first mover advantage but the possibility is always there for its position to be supplanted by a fork, creating a social imperative to manage contributions in a satisfactory manor to her community. 

GitHub is truly a system of anarchism, in the most classic sense of the term. It is a system of communication and contribution that is without a central organization or institution of governance. Sure, it is hosted, developed, and maintained by someone but they do not enforce any set of governance or process over the users of the system. 

It is my belief that we are, right now, in the middle of a very large evolution in the ecology of open source. The language of contribution has infected a new generation of open source contributors. Much of the potential first imagined by open source pioneers is being realized by high school kids on a daily basis who contribute effectively with less effort than has ever been required.

The post goes on to discuss the bias of Apache to Subversion as a repository.

The Git versus Subversion has a long history but that has mainly been a comparison of features. For me that is like comparing the features of television versus radio, or books versus ebooks. Mikeal's argument is a more important and an interesting view. I'm looking at the influence of the underlying technologies.

Git is not Subversion. They are different media, different technologies. Different media do not allow the same content. Just as a newspaper cannot tell a story the same way as television, so too Git projects will not be the same as Subversion projects. You cannot cram a GitHub project into subversion. People are also using GitHub for writing blogs, books and many different ways than simply a code repository. As Mikael points out there is substantial communications in the hub. The technologies are different. What is created is different.

The GitHub revolution is part of a larger cultural change. As Om Malik pointed out, Dribble and SoundCloud are part of this revolution. The results of Hackatons, Camps and Startup Weekends are impressive. These projects, services, projects and communities are our new cultural artefacts which are changing hiring practices and people's identity.

The definition of Open Source is also changing perhaps to the breaking point. We probably need a new term to describe the content being created on these platforms. Times are changing.

A technology choice is important and Mikeal has provided a strong argument for choosing GitHub. In addition, I expect that in the future we may see less companies choose the Apache way, just as a generation ago we saw companies no longer see the need to move from NASDAQ to the NYSE.

Speaking after Steve Jobs introduces the Mac

On January 22, 1984 the Mac was introduced with the very famous Apple SuperBowl ad. It was spectacular. Steve Jobs did his famous keynote two days later to introduce the Mac. 27 years ago the web did not instantly let customers watch Steve Jobs and his presentation skills were just becoming known. Not many people saw the Mac keynote. So he hit the road to SoftCon to show the software support for the new computer.

SoftCon, was held on month later in New Orleans. I regularly gave talks about software retailing having started the first software store in 1979. We had a small chain of stores at that time. I was scheduled to speak on the good and bad of software packaging.

Enter Steve Jobs. In a very large room he introduces the Mac to the software industry. This was a big moment. He showed the $1.5 million dollar Ridley Scott ad, professional slides and had a large staff.  He was well prepared and had masterful timing. Thousands of people in the room applauded when he finished.

I was on next. I had to speak after Steve Jobs. It really didn't matter that my presentation was 35mm slides after professional photos. I had no Ridley Scott ad. I had nothing. The topic of software packaging was insignificant after seeing the Mac for the first time. The legibility of software titles was not as important. I hurried through my talk and sat down. It was exhausting.

Soon after I bought a Mac. 

The New Framework Discussion (Part One)

mikeal posted "A new direction for web applications" And I left the following comment.

I agree about MVC is not the right fit. For me it breaks down even for Rails with JavaScript on the client. Model is database term that does not fit async data. RESTful is certainly part of the mix as are other HTTP inputs and IP streams. These don't fit the model analogy either. 

The "new" framework is probably much more of a mosaic than a flow (or flowchart). Not certain how well the neighbors (parts of the mosaic) know each other. Probably some zoning laws, but everyone is able to do their own thing (except after midnight) so long as certain ordinances are not broken. 

My other thought is that these new apps are much like a room full of people. Conversations between a few people are great. Lectures work. But getting a room to act together requires something like Roberts Rules of Order. 

Writing internet code is certainly has a long way to go.

I wanted to expand on that post and comment about the New Framework. I think there are several influences shaping its development.

1. Async. The first big push was Ajax. The latest is node.js. Data no longer has a flow or a sequence, it is more quantum. REST is the structure for async.
2. Speed. Look at the popularity of Steve Souders and Nicholas Zakas talks and books on speed. I hope the new framework fits the techniques they and others are discussing. For example, fewer requests doesn't always play well with frameworks that generate lots of directories and files.
3. Events. Even a small app has a population of events. The new framework must provide a logical structure to these events.
4. CSS, HTML and JS. Most of us work with all three. For example, what use to be in JS is now often in HTML5. The new framework will have to consider all three.
5. History. Presenters are going back and looking at the development of other technologies and looking for good patterns. Douglas Crockford was looking at the transition from manuscripts to books in his talk at CapitolJS. This search is common for any new technology. Marshall McLuhan showed that a new technology retrieves an older technology. It will be interesting to see what is retrieved by the new framework.
6. Testing. Of course.

You can probably argue that there are other forces at work here. For example, I could argue pro and cons of templating. 

I'm sure someone is working on the new framework right now, it is "just now well distributed" yet.