I go to lots of conferences. Each year, I meet more and more people who have Twitter accounts. Broadcasting updates with Twitter also happens to be a convenient way to self-organize.
For example, if you want to tell your friends at RubyConf that you’re going to grab sushi? Perfect: write tweet, use the #rubyconf hashtag, press Tweet. Folks in your circle will know how to find you. Unfortunately, everyone else will have no idea what you’re talking about. “rub y conf? Who is 'y' and why are we rubbing him?”
I’m a private individual. I’m also a considerate individual who hates cluttering up someone else’s stream. About a year ago, some friends and I setup Twitter so that we could send group text messages between each other privately. Tweets sent to an account were broadcasted to everyone who followed, and followed back, by that account. It’s a free group texting hack.
If you’re a technical person, here’s how it works.
-
Setup a separate Twitter account. Let’s call it @nerds_list. This account will act as the group’s hub. Direct messages sent to this account will send those direct messages to everyone else in the hub.
-
Install Linux, setup Ruby, and run the following program.
require 'twitter'
client = Twitter::Base.new(Twitter::HTTPAuth.new('nerds_list', PASSWORD))
last_id = 1408167803 # or whatever the previous was
loop do
client.direct_messages(:since_id => last_id).each do |dm|
client.update("#{dm.sender.screen_name}: #{dm.text}")
last_id = [last_id, dm.id].max
end
sleep 60
end
-
Tell your friends to follow @nerds_list and have @nerds_list follow your friends back. It’s important that the follow relationship goes both ways.
-
Tell your friends to update their profile with the mobile number and to turn on DM notifications.
-
To broadcast a message to the group, send a DM to @nerds_list. The server will receive your message and broadcast the update to all your friends.
Not a technical user? Not to worry several amazing applications have popped up, over the last year, that allow you to do private group chat much easier.
-
Belugapods is a private group messaging service made ridiculously easy with the availability of mobile apps on both iPhone and Android. Beluga is done really done well.
-
Convore is a quick way to instant message with groups of friends in real-time. You can join public and private groups to talk about anything.
-
Privatelyapp, which was built by Les Hill who wanted to have private conversations with his Twitter followers. I’m @heisenthought on Twitter, follow me and I’ll send you an invite.
Special thanks to Tom Robinson for writing this script.
If you’re a software professional in Phoenix, Arizona, here are several active developer groups that I recommend. This list isn’t comprehensive, but it is a summary meet ups that I think are worth checking out.
-
Phoenix Java User’s Group. The PhxJUG is the largest gathering of Java developers in Phoenix. Past topics have covered a broad range of JVM related technologies including Grails, Scala, JRuby GWT, and other real world applications of the Java programming language. The PhxJUG is one of the oldest and longest successfully run developer groups in Tempe, AZ.
-
Phoenix Ruby User Group and Phoenix Rails User Group. The Phoenix metro has two Ruby-centric user groups, RubyAZ and PhxRails. The former focuses on broader Ruby topics while the latter focuses on areas around Ruby on Rails. Both groups host monthly presentations and have strong community participation. Occasionally, the groups hold a demo-night, where developers can showcase their latest tech, and a hacknight where developers can collaborate with each other.
-
Phoenix Android Developer Group. The Phoenix Android developer group has grown into the place to meet other Android software developers, hardware hackers, and mobile enthusiasts in Phoenix and the greater Phoenix metropolitan area. The current set of monthly presentations are aimed at novices. There’s also a monthly hacknight where developers can collaborate with each other. Disclaimer: I organize the Phoenix Android Developer Group.
-
For OS X, iPad and iPhone developers. There’s a lot going for OS X and Cocoa developers. For iPhone and iPad developers, the iPhone Developer Group hosts a monthly presentation. For general OS X and Cocoa development, the Phoenix CocoaHeads host a monthly meeting. And if you want to collaborate with other developers, there’s also weekly NSCoderNight.
-
Phoenix Scrum User Group. Practice Agile? That’s great, because Phoenix also has a very well organized Scrum user group, PhxSUG. Past topics have included presentations on Agile techniques, featured speakers, and role playing games involving audience participation.
-
HeatSync Labs. If you enjoy working with both hardware and software, own a subscription to Make magazine, and don’t mind getting your hands dirty, then you may want to join HeatSync Labs. HSL hosts weekly meet ups as well as a monthly Arduino meeting.
-
Various lunch meet ups. The best part of a meet up, is after hour dinner and drinks. Developers in Phoenix have three meet ups aimed at lunch time nerding: Tempe Nerds, Tech South Lunch, and Geek and Eat.
In addition to the monthly and weekly meet ups, there are several local conferences put on by our local developer community.
-
Developer Ignite Phoenix. Developer Ignite is based on the Ignite model of presentation delivery, where speakers have 5 minutes and 20 slides automatically transitioning. Though the presentations are brief, it’s a great way to hear about technologies from software developers around Phoenix.
-
Desert Code Camp. Desert Code Camp is the longest running camps organized by developers and for developers. I’ve been attending Desert Code Camp since 2006. Even though the talks are dominated by Microsoft technologies, it’s still a great way to network and meet other passionate developers in the community.
This year also saw the creation of two new developer groups.
-
PhxData. PhxData grew out of the Great American Hackathon which I organized last year. After the hackathon, we realized that mixing journalists and technologists produced remarkable ideas. I co-founded PhxData to unite technologists in the Phoenix area who are engaged in data mining, parsing, visualization, etc. It also serves as a platform for journalists and government officials to connect with technologists who want to take public data and make it useful.
-
JavaScript-AZ. The JavaScript group is just starting out, but I expect it’s popularity to grow over the next few months.
You can learn a lot by meeting and connecting with other developers. I highly recommend taking the time out of your week to connect up with a group and even offer to give a presentation.
“What is a haiku?”
From wikipedia:
“Haiku is a form of Japanese poetry, consisting of 17 syllables, in three metrical phrases of 5, 7, and 5 syllables respectively.”
Personally, I prefer the way Stephany, an early haikuist describes the way of the haiku:
To write a Haiku
Five then Seven, Five again
Simple, yet complex
And with that, I’d like to introduce you to a fun project that I’ve been working on for a few months. It’s called the Haikuist and it’s aimed at people that love composing haiku poetry.
“What is haikuist.com?”
Haikuist.com
Poetic micro-blogging
for haiku lovers.
Haikuist first began as a place to keep track of my random acts of haiku writings. Also, it stemmed from my deep frustration of the growing number of badly formed haiku being published on the internet. Counting syllables should be easier, so I did what every problem solving software engineer would do: write code!
Syllable detection isn’t technically the most trivial thing to solve, but what started as a 200 line Ruby1 program eventually grew into what you see today at haikuist.com.
I’m extremely excited about Haikuist. It’s fast, simple to use, and offers fascinating insight into the minds of creative people. I am surprised at how poetic people can be.
Haikuist is a work in progress and will continue to improve over time. Sign up at today and invite your friends along for the ride, you may be surprised by what they say.
This past Labour Day weekend, I redid this entire blog in HTML 5. Here are some of the notes I took while diving into HTML 5.
The first thing to keep in mind is that HTML 5 is a work in progress and will continue to be until there exists two browsers with complete HTML 5 implementations. Remember this as you read the various W3C specs, wiki entries, and blog posts–including this one.
Web Developer’s Guide to HTML 5
-
The Web Developer’s Guide to HTML 5 is a good introduction to HTML 5 from an HTML author’s perspective. The biggest takeaway is that there are two syntax modes to HTML 5: Regular HTML syntax and XHTML syntax.
-
After understanding the differences between HTML and XHTML, going with XHTML makes more sense. The syntax is more strict, yet simpler and consistent since it follows XML syntactic requirements. HTML mode permits all sorts of exceptions, which ends up being a PITA to remember. For example, empty attributes (<input disabled>...</div>) is valid HTML, but invalid XHTML. I almost never remember this. I suspect that HTML support is for backwards compatibility reasons (since shipping a browser that breaks ten trillion web pages is evil).
-
For the rest of this post “HTML” means HTML 5 in regular HTML mode, and “XHTML” means HTML 5 in XHTML mode.
-
Using XHTML requires content to be served with a Content-Type of application/xhtml+xml, though in practice this doesn’t seem to be causing a huge problem. There are reasons for not obeying this, for instance HTML 5 allows authors to publish polyglot documents which conform to both HTML and XHTML. More on this below.
-
The other big note is the DOCTYPE, which is used to determine quirks mode rendering.
-
The DOCTYPE declaration isn’t technically required for XHTML documents since they are meant to be delivered with the correct XML MIME type thus instructing the browser to process it as XML in no quirks mode. I set it anyway since it ensures the most standards compliant rendering (It also gives me warm fuzzies).
HTML5 differences from HTML4
-
The next good read is HTML5 differences from HTML4. The most interesting thing I gleaned from this document is when it’s authors consider HTML 5 complete: “The HTML5 specification will not be considered finished before there are at least two complete implementations of the specification. This is a different approach than previous versions of HTML had. The goal is to ensure that the specification is implementable and usable by designers and developers once it is finished.” Pragmatic and competitive. I like this approach as it allows future browser implementors (however unlikely they are) to have access to two reference implementations.
-
To help you decide whether or not to adopt HTML 5, you can review the current state of the various browser implementations and also the comparisons between HTML 5 layout engines. Also make sure to check out the W3Schools’ browser statistics, which lists browser usage and trends on a month-by-month basis.
-
It’s very clear that HTML 5 is going to be a lot of things. It looks like they’re revisiting a lot of existing semantics (such as “the definition of URL” and “the origin concept”) and standardizing on their definitions.
-
I previously mentioned that HTML 5 allows authors to construct polyglot documents. One reason for this is so other markup languages like MathML and SVG can be included in the same document, but only in HTML mode.
-
The document then goes on to outline changes in elements and attributes. There are well over two dozen new elements addressing everything from document publishing (<section>, <article>, <header>, <footer>, <nav>), accessibility (<hidden>, <progress>), typography (<ruby>), and visualization (<canvas>) needs. Elements are also removed, notably support for <frames> which we all know has brain damaging affects on usability and accessibility.
Practical Resources
If you have any other great sources on getting started with HTML 5, make sure to share them in the comments below.
What follows are some strong opinions I have regarding software development. Most of these aren’t original, but together, they form the framework for how I think about software and it’s design and development in a production environment.
In no particular order:
-
Software engineering is a discipline. You don’t master the art of software engineer just because you have a passion, a hobby, a degree from a university, or a book titled “C++ in 365 days”. These factors may help, but it’s discipline that keeps you practicing, studying, and applying the scientific method, which ultimately makes you a better software engineer.
-
Focus on delivering value to customers. If you’re write it, test it, buy it, sell it, pay for it, run it, own it, or use it, you are a customer. Any single project or organization will have multiple customers. Figure out who your customers are and how to maximize their collective goals.
-
Reading software should be a pleasure. Good software reveals it intentions by following conventions and using design patterns. If software is primarily read by other software engineers, it should be written in a manner for other software engineers to read. Sometimes this manner is called a domain specific language.
-
Learn to build, follow, and break conventions. Conventions exist everywhere either by accident (a recurring pattern) or intentionally (by design). A team should follow conventions and also establish them when they don’t exist or capture them when they begin to emerge. Keep in mind that even conventions can have scalability issues. Teams should recognize when an existing convention stops scaling and introduce new ones. For large bodies of software every piece should have a place, and every place should have it’s piece.
-
Keep things simple by recognizing high compute costs. Never try to design everything up front and all at once. When developing new features, it’s easier to do so on top of components that are small and decoupled rather than large and complex. That’s why it’s important to start work by doing the simplest thing possible.
-
Testing is important, but not as important as strong team communication. A program with 100% test coverage doesn’t imply that it’s 100% functional. In fact, that opinion is extremely dangerous since it’s possible to have a busted program with 100% test coverage. Better communication will always beat better coverage.
-
Building products is a team sport. Finding the right people, motivating them, and putting them in the right positions is key to the success of a product. Don’t just hire someone for what they already know, hire them because of their ability to learn. The idea that great products are built by people in silos is no longer the truth. Collaboration and different perspectives make a better team and build a better product.
-
Writing testable code is the trick to writing reusable code. If you’re having a hard time isolating a piece of code, it’ll generally imply you’re going to have a hard time reusing it.
-
Code reusability isn’t as important as code usability. An API should be usable much like a user interface: it should be clear to users, simple to use, provide shortcuts for commonly completed activities, and consistent.
