JSConf 2013 Speaker: JavaScript Journalism

I'm honored to be accepted as a speaker at JSConf 2013. I'll be speaking on JavaScript Journalism.

It is time that news stories told with JavaScript get recognized as a form of journalism. It took years for photo journalism to get the recognition it deserves, now is the time to recognize JS Journalism. 

Most news organizations presented election news using JavaScript. News home pages often have more JS than text. 

A bit of history. A bit of academia. A bit of current news. A few guesses about the future. But nothing about the future of newspapers.

UPDATE: Here is the slide deck and examples.

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

Update to Roger McNamee's TED Talk, Watch This One

This version of the talk includes a hypothesis about many personal screens that leads to discussing the cloud. To borrow a phrase, "It is the screens, stupid."

http://fora.tv/2011/06/28/Elevation_Partners_Director_and_Co-Founder_Roger_McNamee#fullprogram

Why JavaScript and #jsconf matter

JavaScript is the key to HTML5 as described above.

My JSConf ToDo List

With great anticipation, I will attend JSConf and NodeConf. To get the most out of that time, there are a few items I want to brush up on prior to hitching up the wagon and heading West. I've got a list, some big and some small and in no particular order.

1. Full Sail Ale. jsbeer prep is first on the list.
2. Eloquent JavaScript. Finish reading especially the object oriented chapter.
3. jquery mobile alpha4. Convert some code including j360.
4. Sencha. Run through the tutorials and screencasts.
5. learn about SASS
6. jquery plugin. Write a very simple plugin.
7. outrigger app site. Create landing page about outrigger app.
8. outrigger app. Finish demo data. Ready phonegap feature.
9. get new Android phone and install couchdb. Make iphone into an ipad touch for Civ
10. learn git well enough to be comfortable with github
11. put j360 into git and write readme
12. use build.phonegap for j360 and outrigger
13. colossal caves into github
14. hours reading nodejs blogs and reinstalling on my laptop
15. put code into a js module, maybe my search parser
16. publish regex attribute for input tutorial for Coding JS Apps http://jsapps.posterous.com/
17. fix raydaly.com and raydaly.org
18. publish "New Enterprise Network" talking paper
19. use ace
20. publish on Coding JS Apps an article on using couchdb as development environmen
21. new photo for my blogs, twitter, google, quora and facebook
22. hitch up the wagon

I'll probably add to the list and update this post. As I reread the speakers applications, I'll probably get inspired to do more. This blog or my Coding JS Apps blog will have the results.

Also I need to review what I wrote after last year's JSConf:  a pesky list of ToDos.

15 Years of WebApps in JavaScript

15 years ago on January 23, 1996, HTMLjive - an HTML editor written in JavaScript was release. It is considered the first serious JavaScript program. In short order, it went viral, was on websites around the world and translated into several languages.

HTMLjive was a simple HTML editor but it incorporated a preview window, three modes of HTML coding and on-screen help. The inline HTML editors, like the one I'm using right now to write this blog, have added features, but HTMLjive had the basic features you take for granted today.

I am often asked, "Did you expected JavaScript application (web apps) to become popular?" Yes. Shortly after HTMLjive was released, I starting writing the book "Using JavaScript" with several co-authors. One of my great memories is giving an author talk called "JavaScript Makes Your Site An Application" at a local book store a few months later. So, absolutely.

The community that supports JavaScript has come a long way since. Brendan Eich, father of JavaScript, has received the recognition he deserves. Douglas Crockford gave us JSON and is the JavaScript evangelist. Ajax pushed the language back into popularity and Google showed what could be done with Google Maps and Gmail. Now the annual JSconf features the greatest advances, technologies and speakers. Most of the people that deserve a mention for their contributions to the community were or are speakers at JSconfs.

JavaScript is no longer just for the browser. My web apps, both mobile and desktop, have JavaScript on both the browser with libraries like jquery and on the server with couchdb and node.js. Thank you to the community. It continues to be a joy to code in JS because of you.

Dave's plan to rethink RSS has potential. I've always liked the simple concept of title, link, description (text) and categories. Making a RESTful, JSON API would be great. I've been dabbling towards that with a project I've been working on that started with Zlides.com and OPML combined with JQuery Mobile. So I've been giving this some thought.
Dave likes Twitter. The Twitter API is proven itself and lessons have been learned. Lots of people know it. So my comments below reflect my usage of the Twitter API, particularly the search API.

1. JSONP. The ReallySimple API should support JSONP. The primary benefit is cross-domain support so I can write browers apps hosted on any site and use the reallysimple.org api. This would make it much easier to write mobile apps using JavaScript, HTML5 and CSS. For an example, look at the Twitter Search wiki and how they support JSONP. Also look a jquery's support for JSONP.
2. Categories. RSS has always supported categories and I was rather suprised not to see them in the API. Much of web 2.0 worked leveraged categoris and I think it is an important addition.
3. RESTful. Several people have commented on using the RESTful verbs. I certainly support that for GET and POST but since DELETE and PUT are harder to implement there should be more discussion of that.
   
4. Extending Really Simple. RSS supports namespaces and there should be someway to extend the Really Simple api. Steve Moyer commented about having extra fields like _rev in the API. In my view, extra fields would be fine but probably ignored by most clients. It would probably be better to suppress them, but in some implementations there are cases were the extra fields would add a feature. More discussion needed.
5. getPost. Given an idPost, I would want to get the JSON for just that post. The id could be the permalink. And perhaps, maybe I supply a link and get back an array of posts which could be all of the comments made to a post.
6. Enclosure. Very encouraged to see it supported. Important in this world of videos, photo blogs and other media files.
7. OAuth. Twitter and others have moved away from basic authentication for a reason. I would suggest supporting OAuth like twitter.
   
8. No date. The format of title, description and link is so powerful that it applies to more than just reverse chronological blogs. The web content management system (CMS) that I wrote had RSS feeds as its foundation. [I'll have to add the ReallySimple API to it.]  And see example of Wikipedia below. However, I would think that this might be an expected field. Or perhaps it is better to ignore it for right now given the discussion that will start about date format.
   

ReallySimple maps to ReallySimple HTML pages as well. It supports title, link, description and hopefully category. This also maps directly to standard Web 1.0 content web pages where one HTML page contains content on a subject. For example, this Wikipedia page on Daly Languages has a title and obviously a link. The content is inside the body tag, less the navigation, footers and banners. Categories in the metadata and displayed on the page. So I should be able to take the primary content of this page and easily put it into a JSON message using the ReallySimple fields. Lots of features could be built off having an entire page in JSON.

I look forward to using the ReallySimple API with mobile apps and Couchdb apps.

Cross posted from: http://raydaly.posterous.com/really-simple-api-first-comments

ToDo After jsconf

jsconf was even better this year than last. A good part of that is because JavaScript and the JavaScript industry is better than last year. Missed most of the Track B talks and I hope to get caught up by watching videos. But most of my spare time may be taken up by the ToDos I wrote myself during the talks. Thought I'd share those.

1. node.js Wow - it has simply changed everything. Even if the API is constantly changing, I've got to get it installed and start using it. Needs screencasts.
2. (fab) - Mindblowing - fab:: more twitter than blogging. Just a completely new way of thinking of things and I have to try it. Also, it shows the impact of node.
3. Google Chrome Framework - Had not thought about it enough until jsconf. This will be so important to my work project. But everyone should add the meta tag to their JS pages. I have to install it at work asap and on a few other desktops.
4. yayQuery - Been following on tweeter, now I've got to listen to the podcasts. Clearly the next generation of javascript and funny.
5. Raphael - Years ago I wanted a visual, historical, problem solving site base on timelines (timeography.com). Now this is the js library to make it happen. Usable for for ANY type of vector graphics and I can not wait to push it. Reminds me of RIP for BBSs.
6. Progressive Enhancements - Jenn made the most convincing case of any presentation. I will be reading up.
7. Interface Builders - Ares and Greenhouse demos were good. Of course there is the Mac tool. I need to more take time and look at all of these -- another skill I need.
8. SproutCore - More than a year ago I was a real fan of SproutCore. I had previously argued at a Ruby meetup that MVC was broken in Rails because of the mix of data with code in the view and that the server should only produce JSON. Now that SproutCore is at 1.0 and gives me MVC on the client - will time allow a deep try? Looks so good too.
9. CVC - Client View Controller by Kyle Simpson pushes the same anti-MVC argument that I was making but puts the same JavaScript on the client and server. Again an incluence of node. Love the concept and certain that is is how the future will go, but it looks like handlebar.js and bikechain.js need to be more battle tested. Have to test to tell
10. Couchdb - The talk was on evently, but it is really Couchdb that stills interests me. Two tier solution with JavaScript and JSON. Think this will be the solution for one current project. jquery.couch.js here I come.
11. xui - prior to jsconf I went to phonegap training and heard about xui again. It would be great if jqtouch could be build on xui.
12. yql - definitely in my toolbox now

Other sessions were also great and I learned lots. For example, Facebook really showed the importance of refactoring in the browser platform. And see previous post on Socratic. And who can forget Gordon. The above are my ToDo list and possible suggestions for your exploration.

Socratic and Verbalization: Documenting on both sides

Francisco Tolmasky gave a talk at #jsconf on Socratic: Documentation Done Right. He asked for feedback and he got me thinking about the problem that coders documentation does not even help them when they go back to it. Ever have that happen with your documentation? Go back to your source comments three months later and they don't make much sense?
The process of coding involves variable and method names which are suppose to be meaningful. A convention has evolved where methods should be verbs because they do something and variables are nouns. Roughly.
So I suggested to Francisco that perhaps Socratic could use Verbalization to verify that methods are verbs. Think of Verbalization as a spell check of only verbs. Maybe it could check that "is" methods are boolean and perhaps more. I suppose the Nounization could be done on variables.
One theme at JSCONF is running JavaScript on client and the server. For example, same validation method on both. This got me thinking about the documentation divide. So why not run Verbalization on both Socratic and Textmate or your IDE. As you build out your code check that your method names are verbs. And this gets you a glossary? So a common plug system for both Socratic and IDEs would be good.
Just a thought or two with a lot more to think about.