ABCEDmindedness

Reading, Bookmarks and Pads

2012-01-19T09:44:00.000-05:00

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

2012-01-13T10:47:00.000-05:00

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

2012-01-12T10:40:00.000-05:00

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. (Stackoverflow has other recommendations.)

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

2012-01-11T10:08:00.000-05:00

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.

Your mobile resume. Rewrite your resume into jQueryMobile.
Learnmobile. Rewrite this post into a mobile app.
Your mobile apps. Link to all of your mobile apps in dropbox. Update weekly.
Favorite recipes. Make a list of food you make often with pictures or videos.
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.

dynamic list - store data in Json, read Json and create list. Convert you mobile apps dynamic.
add to list - create a list that can be added to and stored in local storage.
todo - perhaps the most common app people try. Keep it simple.
rate it - provide a list of items to be rated and resort list after each rating
#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

2012-01-10T16:33:00.000-05:00

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

2012-01-10T11:08:00.000-05:00

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

2011-12-29T08:45:00.000-05:00

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

2011-11-24T03:11:00.001-05:00

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

2011-10-06T12:21:00.000-04:00

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)

2011-09-28T09:39:00.000-04:00

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.

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.
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.
Events. Even a small app has a population of events. The new framework must provide a logical structure to these events.
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.
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.
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.

CapitolJS 2011 [#JSConf East and #capjs]

2011-09-19T12:39:00.000-04:00

One attends a JavaScript conference to learn how to use the language better. The conference is not intended to teach the beginner. There are assumptions of a working knowledge of the language, probably extensive experience in coding and an interest in node.js. However, I think there were themes or lessons in the presentations at this conference that would help any JavaScript developer.

The future of the language is amazingly bright. Mike Taylor showed that even though the browser Navigator has very unreliable properties that the future new properties (e.g., online, geolocation, etc.) hold great promise. Pamela Fox had example after example of APIs that JavaScript can access for functionality, public data and user data. And Brendan Eich demonstrated the work that Intel has done to access parallel-processing power with an engine called RiverTrail (on github) [Infoworld article][http://www.infoworld.com/d/application-development/intel-river-trail-adds-parallel-dimension-javascript-173347].

Performance in JavaScript is now in the hands of developers now. Nickolas Zakas promoted the use of both defer and async for script loading. So testing must include performance testing with no action taking longer than 100ms. This is the max for a responsive system. Alex Seston also emphasised the need for non-blocking code while on the topic of third party JS. Alex Russel went deep into working web engines in browsers so coders know what is behind some simple DOM changes.

JS, the programming language of the web, is amazingly rich. Douglas Crockford looked at how we code from the viewpoint of Head and Gut (see book Science of Fear) and how the Gut often gets in the way. Using tools and the good parts of the language (language subsetting) we can use our Head more and produce less errors. "Programming requires more precision than writing in English." Language conventions take time. For example the line breaks and spacing introduced by Medieval manuscript copyists. This language history perspective was echoed in Mike Taylor's talk and emphasized by Brendan Eich in noting how young the language is. It is mindblowing what the JS community can code in 140 bytes on Jed Schmidt's site (http://140byt.es.com).

Growth is in mobile and it effects all. Rebecca Murphey showed the new toura mulberry framework for creating content rich mobile apps built atop phonegap. http://toura.github.com/mulberry/ Joe McCann works in the mobile area and provided a comprehensive view of both coding and using node.js with Express, Stylus, Smoosh, and Commander as tools for creating any app. it is clear for the Head to win over Gut that automating tools are needed.

Node.js is still growing. Mikeal Rodgers ran down the most popular packages for node including npm, optimist, request and of course socket.io. But there is still room for improvement, especially in debugging. And again, node was mentioned by most presenters. Ben Combee showed how to access the node running in webOS and stated that webOS will soon be updated to version 0.4.11. Paolo Fraqomeni talked about how the design of node is especially suited for the enterprise and the event emitter.

As I see them available, I'll link to the decks for each presentation.

Douglas Crockford
Ben Combee
Nicholaz Zakas
Mikael Rogers
Jed Schmidt
Mike Taylor UPDATED
Rebecca Murphey
Alex Sexton
Alex Russell
Joe McCann
Paolo Fragomeni
Pamela Fox
Brendan Eich UPDATED

The conference was terrific not only because of the speakers but thanks to the work of my friends Laura and Chris Williams. Also because of sponsors there was time to network at parties both before and after the event.

Thanks. A wonderful community.

UPDATE: Group Photo

Distinction between sites and apps is RSS

2011-09-11T07:37:00.001-04:00

James Pearce wrote a substantial post about the distinction between sites and apps. He says the distinction matters only to developers and not for users. I think there is another measure of the distinction than his fat versus thin client. This is my response.

The distinction is only relevant, as you say, for developers. The reason is simply because "interface is content." Or perhaps put another way "interface is the message."

Take some content and provide a simple HTML interface. Put the same content in a JS/CSS3/HTML5 interface and the message is different. People will "read" it differently and have a different user experience.

So the distinction becomes blurred in my view as soon as you cross the pure HTML line. Ask yourself at what point does adding JS/CSS3/HTML5 take the content from site to app? I suggest there is not a brightline using that (ie. fat client) as a measure.

However, there may be another measure. Again, it may not be a brightline, but it does help.

Sites can support an RSS feed while apps don't.

Let me add to the comment that I left.

The post argues that the distinction fat versus thin, that the code resides on the browser versus the server. It also argues that users don't care.

First, take the New York Times or any newspaper or news source. Does it really matter if I read the story in an app or off their site? They support RSS so I can read the story on other sites, in RSS readers and apps that support RSS.

Then take an app like Pulse or other news apps. I can read an MSNBC story with the app or on the MSNBC site. But I don't find Pulse stories on MSNBC. Pulse cannot support an RSS feed because it does not create stories.

So I would argue that the user experience between the Pulse app and the New York Times app is substantially different because the users know the source of the content. Therefore, as a developer, you'd design the app to the user expectation.

Now that is a simple, legacy example. Let's add some web features. Many sites, not just news sites, all users to comments. Comment systems support RSS feeds or other notification methods (e.g., email). Certainly comments are not an app.

More modern day are sites like Quora. The content is not news stories but there is new, relevant content. They use the headline of "Feed" on the main page. Clearly Quora is a site.

And finally, let's look at the classical app: the todo app. Put a todo app on any smartphone for personal use and all of the generated content can stay on the phone. It would be a useful app without any interaction with the internet. Even if you sync the todos with other devices which would require servers somewhere, the bulk of the app in on the phone. But more importantly the data source is on the phone. You could sync with RSS (or a JSON equivalent) but is that feed really useful for the public? It is core to the purpose?

In summary, you've got a site when the content supports a RSS feed. The purpose of an app is confined to the device. The distinction my not matter to developers, but user know when a site can support an RSS feed, even if they don't know what RSS is.

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

2011-07-22T09:50:00.003-04:00

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

2011-07-22T04:37:00.000-04:00

JavaScript is the key to HTML5 as described above.

My JSConf ToDo List

2011-04-05T21:20:00.001-04:00

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.

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

2011-01-23T07:31:00.002-05:00

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.

2011-01-11T05:26:00.000-05:00

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.

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.
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.
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.
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.
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.
Enclosure. Very encouraged to see it supported. Important in this world of videos, photo blogs and other media files.
OAuth. Twitter and others have moved away from basic authentication for a reason. I would suggest supporting OAuth like twitter.
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

Recommended Beers of 2010

2011-01-01T13:20:00.000-05:00

This was a great year for beer in Northern Virginia. Full Sail is now distributed and Great Divide's beers are more widely available. Also, Bob Tupper got back into business after a few years of dryness. Finally, Church Key opened a few block from my office in DC. Hope you have a chance to try some of these beers this year.

Great Divide - Collette This is a special. Grab as much as you can when you see it. I spent a night driving from store to store buying everything that was left. The focus on this beer is not the hops, but the yeast. It is a different taste. This is a farm house ale with yeast in the bottle. My friends laugh at me because my pours end up with overflowing heads. Great in the spring or summer. We had it the other night with Raclette and it was excellent.

Great Divide - Titan IPA We first discovered this perfect IPA from Great Divide before the Collete. It is great when a brewery makes a beer so good that you want to try everything that they produce. The balance in the IPA between the hops is totally refreshing and not overwhelming like others fighting the hop wars. I'm never disappointed when pulling one of these out of the fridge.

Appalacian - Hoppy Trails IPA This IPA made me really appreciate the IPA style. It made be go back and try some others again like Full Sail. The semi-high alcohol punch of an IPA has to be balanced with a strong hoppy flavor supported by a robust malt. A regular in my fridge.

Tupper's Hop Pocket Ale Bob Tupper introduced me to so many different beers at the Brick. I was thrilled when Old Dominion started brewing his Ale because I knew he liked Celebration Ale. This was my friend's favorite until Tupper pulled it from Old Dominion. After a long hiatus, Bob found a brewery and his Ale is back. Dominion did a better job, but still wonderful to have it back.

Schlafly - Christmas Ale Normally this spot would be reserved for Sierra Nevada's Celebration Ale. But this spot opened up this year because of the disastrous change in the recipe. But Schlfly's might have made it anyway. The hint of orange made it a wonderful taste in a full ale for the season. I recommended it to everyone in my annual Christmas Beer tasting this year.

Heavy Seas - Winter Storm I've enjoyed this for the past several Christmas seasons. It is now my favorite Christmas ale with a great Extra Special Bitter flavor. I'll stock up this ale. Nearly a perfect cold night brew to warm your bones. Arrg!

Breckenridge - Extra ESB I love ESBs. My favorite was Fredrick's Red Ale, but that is now defunct. Had another great one in New Orleans about 10 years ago. It is so hard to find a good one, nevertheless a perfect one. Breckenridge's is not perfect but better than good. It is amazingly consistent. ESBs can be so smooth. I keep this one around.

Full Sail - Pale Ale. About 20 years ago at the Brickskeller the bartender introduced me to Full Sail Ale and Red Seal Ale. They were mana from heaven. They would be my first request when walking down those stairs and seeing all the cans. But distribution stopped and I finally gave up the search. I had to visit the brewery when in Oregon but never expected to see it back on the East Coast. This was the great surprise of the year. And try their IPA as well. Both wonderful.

Full Sail - Session Found this at a bar and have stocked up with both the regular and the dark Session. It comes in a Red Stripe like bottle and is a tasty lager with only 4% alcohol. Often I don't need the full IPA punch so this is a tasty alternative. Expect it to be a regular this summer.

Bell's - Oberon Our summer beer for the past few summers. I cannot help but think about a warm summer day and the pleasant taste of this wheat beer. You know summer has arrived when Oberon is on the shelves. Coming again soon.

Recommended Books of 2010

2010-12-31T22:07:00.000-05:00

Books of 2010

Probably because of ebook without DRM from O'Reilly, there are substantial more books on this year's list that previous year. However, I don't think I finished as many this year. The range is about the same with fewer home improvement and more technical books. The highly recommended are listed below with a few other notes.

What Technology Wants gets my highest recommendation even though I'm still reading it. It is so good, I'm in no hurry. At first I was very skeptical that I could be convinced the technology ever wants anything, Kelly is persuading me. I compare it to the books by Jared Diamond like Collapse. Those books are like Ancient History while Kelly's book is like Modern History.

Switch: How to Change When Change Is Hard really changed my perspective of my organization. I believe change is hard at any organization that is larger than 300 or so. This book provides example of how change that transformed large companies. Also, lots of economic and behavioral research. The only pdf about presentation was critical to reshaping the introduction to my major presentation last spring and the concept is now taking hold. The Heath brothers older book, Made To Stick, is also recommended.

Cognitive Surplus deserves the recognition that it has received. For the past several years, since Tipping Point, it has been easier to find so called "economic" books that read more like urban anthropology books. This is the best one along that vein this year. It will be interesting to review after I finish What Technology Wants.

High Performance JavaScript is killer. It really shows how far JavaScript has come as a serious language. In working on a team project that was 98% JavaScript, I constantly refereed to this book. Search the ebook really improved my work. If you are serious about JavaScript this book is in your library.

Start Small, Stay Small was purchased directly from the author online as an ebook just as I had purchased Getting Real from 37 Signals a few years ago. Walling talks about start-ups from the developer viewpoint. He makes an excellent case about marketing from day one and out-sourcing the developer work even though you might be a developer. Much more practical that Rework, which I found tired, but that maybe because I regularly read the 37 Signals blog.

App Savvy and Tapworthy are two excellent books about building and marketing mobile apps. While the focus is on the iphone, the advice works for nearly any mobile device. Maybe this is a factor of being ebooks, but it is hard for me to distinguish between the two. I've referred to both while working on an idea of an app. After the proof of concept, I expect to re-read both as I write up a marketing plan. Finally, O'Reilly's webinar lead me to these books and I recommend watching a few during the coming year.

The Book of Gossage is this year's McLuhan book for me. Gossage was the SanFrancisco ad man that worked with McLuhan to convince the world that McLuhan was important. Included in the book is "Understanding McLuhan" which is an excellent article.

More Not So Big Solutions for Your Home was better than the other kitchen books I either bought or borrowed from the library. Mostly old articles from the defunct Inspired House magazine, it got me unstuck on the redesign of our kitchen - which is next year's project.

Possible additions.There are a few on the list below that I cannot yet recommend. I'm behind on my reading but these look very promising from my reading so far. Where Good Ideas Come From is certain to be read soon and I expect to recommend it. Taming Text's focus on text and not media is refreshing. It may stand the test of time. Business Model Generation looks awesome, but I gave it as a gift, so it maybe a while until I read it. Buy the print version of this one. Sometime in the future, I'll have to review all of the economic, research books like Sway and Drive.

Good reading to you.

List of 2010 Books

The Investment Answer
Business Model Generation
Sway: The Irresistible Pull of Irrational Behavior
The Food Matters Cookbook
The Book of Gossage
Where Good Ideas Come From
What Technology Wants
McLuhan: A Guide for the Perplexed
The Creation of the Media
More Not So Big Solutions for Your Home
Cognitive Surplus
Rapid Problem Solving with Post-It Notes
Drive: The Surprising Truth About What Motivates Us
Kitchens That Work
Rocket Surgery Made Easy
Rework
Unfolding the Napkin
Switch: How to Change When Change Is Hard
JavaScript Patterns
App Savvy
CSS Cookbook
JavaScript Cookbook
Tapworthy
Regular Expressions Cookbook
Apache Cookbook
Search Patterns
Designing Web Interfaces
Designing Social Interfaces
High Performance JavaScript
RESTful Web Service Cookbook
Start Small, Stay Small
Event Processing In Action
Pragmatic Version Control: Using Git
Algorithms of the Intelligent Web
Web Design for Developers
Taming Text

HP Buys Palm for the slate market runing JS Apps

2010-05-01T04:59:00.003-04:00

Company acquisitions are viewed as potential for the new company. "By acquiring this product the new company can expand into this market of the old company." More often, the acquiring company places value in old company as a defensive move. They don't want to be outflanked in the changing market place.

The world of mobile devices has changed dramatically in the past 12 months, but people for the most part are just getting use to what it was like 12 months ago. Example, everyone thinks App Stores are it.

First big change: App Stores are old school. Native apps are old school. The great new apps will be not be native apps written in Java or Objective-Whatever. They will be HTML5, CSS and JavaScript apps, hereafter called JS Apps. Proof is the NPR app written for iPad using SproutCore as shown at JSConf. The world has changed.

Second, big change: all major phone platforms can run these JS Apps. Blackberry is just getting caught up with the rest of the market on this. So I can now write an JS App and have it run on all phones: iPhone, Android, Palm and Blackberry. Phones are a commodity for the replacement cycle, though consumers don't know that yet.

Third big change: iPad introduced a new form factor. In part, a larger screen and touch area. This is a big deal, maybe. Market may or may not be huge. May or may not kill the laptop. It is a big deal just because it introduces uncertainty into the laptop market.

Now what is HP to do? The laptop market is being nibbled away by mobile phones or maybe being killed. Things that you only use to be able to do on the road with a laptop can now be done on your phone. You still have customers (and a brand) that depend on your products and you have a product gap that maybe huge. You acquire to fill that gap.

But wait, do your customers realize that products are changing (see above)? Not yet. But you'll be ready for them. Immediately, HP can tell customers we sell phones too. Buying number four in the market never works (see GE and Jack Welch). What was HP thinking?

Go back to third big change: new form factor. The large screens are a field HP knows well - take the keyboard off that laptop and you have a slate. How do you enter this new market? How do you become a leader? Do you take the Microsoft operating system, whatever the name is, and compete with Apple that way? Are you crazy? Too late, too old school. Microsoft has not gotten this right in 20 years. Microsoft is no help this time.

What HP does is work with the trend that mobile devices are becoming a commodity. HP knows that business. They build a slate that runs the JS Apps that also run on the iPhone, the iPad. It also runs the JS Apps written for Android and the Blackberry. Palm has an excellent development platform and team for JS Apps.

So HP buys Palm. They slap the Palm (Pilot) name on the new slate that runs these JS Apps. They are instantly number two in the new market where the App Store advantage is losing marketing power.

And besides, Palm is a better name than tongue twister iPad (or was that iPod). And look at what an old brand name (AT&T) did for Cingular. Brand names are important.

HP bought Palm not because of the phone market, but to hedge their bets in the maybe emerging market of the Palm slate. I can not wait to buy one.

This blog has moved

2010-04-20T22:28:00.003-04:00

This blog is now located at http://blog.abcedmindedness.com/. You will be automatically redirected in 30 seconds, or you may click here. For feed subscribers, please update your feed subscriptions to http://blog.abcedmindedness.com/feeds/posts/default.

This blog has moved

2010-04-20T22:28:00.001-04:00

This blog is now located at __FTP_MIGRATION_NEW_URL__. You will be automatically redirected in 30 seconds, or you may click here. For feed subscribers, please update your feed subscriptions to __FTP_MIGRATION_FEED_URL__.

ToDo After jsconf

2010-04-19T11:36:00.000-04:00

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.

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.
(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.
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.
yayQuery - Been following on tweeter, now I've got to listen to the podcasts. Clearly the next generation of javascript and funny.
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.
Progressive Enhancements - Jenn made the most convincing case of any presentation. I will be reading up.
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.
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.
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
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.
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.
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

2010-04-18T12:37:00.001-04:00

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.

Ed Roberts Passed Away

2010-04-02T12:31:00.000-04:00

A true pioneer of the personal computer, Ed Roberts, passed away yesterday. Bill Gates and Paul Allen released a statement about the creator of the MITS Altair.

I bought one of the first Altair computers, soldered it together and after several tries got it working. Entered many programs using the front panel switches and later built my own keyboard. As soon as it was available I ordered the computer language BASIC on cassette from an unknown company in Albuquerque, NM, called MicroSoft.

Many happy hours were spent at my Altair and it became the platform for my first business venture: CableGames. Though not successful, it lead me into the retail software business and starting the first software store in the world in 1979. That was my career for 15 years.

The world and my life would not been the same without Ed Roberts. I still own my Altair - my first computer.