Text

Social Networks and Inertia

When it comes to social networks we geeks can be very fast and nimble. We’ll jump into any new social network that crops up just to check it out. Besides Facebook and Twitter, most geeks have probably also played with Pinterest, Instagram, Path, Google+, Stamped, GetGlue, etc. Checking out new stuff on the Internet is in our DNA. It’s what we do. When something better comes along we leave the old behind. Remember MySpace? Right.

But the mainstream population doesn’t move quite as fast. Almost everybody we know is on Facebook now but it took years for non-geeks to understand what Facebook is, why they should be a part of it and to sign up and participate. Facebook’s 800 million users aren’t going to start using another social network just because it’s technically better. Geeks don’t care because we’ll go wherever we want to anyway. However, there are some smaller online communities where the inability to move to something new can be a problem. Take Alameda Freecycle for example.

Freecycle is a system where members in a community can exchange things. Instead of throwing something in the garbage you give it to someone else in your local community who wants it. We have our own freecycle community in Alameda as does many other cities and towns. It’s a good thing because it keeps stuff out of landfills while allowing people to easily get rid of stuff they don’t want anymore. Obviously, we need a way to communicate what’s being offered/taken/wanted and arrange pickups. Alameda Freecycle uses Yahoo Groups to facilitate this communication.

I see a few problems with using Yahoo Groups for this purpose.

  • It’s Yahoo. The usability of the web interface is horrible.

  • It’s a mailing list. This is the real root the problem as it requires the user to do a lot of menial work in order to be an effective participant in the community.

  • You need a Yahoo ID or an account with another Yahoo-approved 3rd party authentication provider like Facebook or Gmail. You just can’t type any email address into a field and press the ‘join’ button.

  • You are responsible for organizing the messages. By default emails will start appearing in your inbox. You need to read/delete them or move them somewhere else. If you choose to move them somewhere else you’ll eventually need to deal with them when enough have piled up to become a problem. Old messages will continue to hang around on your computer long after they cease to be relevant. You’re responsible for getting rid of them.

  • If you do choose to keep your freecycle messages in a mail folder separate from everything else you’ll need to create a mail filter to make sure they go there. It needs to be a server-side filter because chances are you have more than one device you receive email on. You probably also want to create a rule to automatically mark the emails as ‘read’ so you don’t see a ridiculously high unread count on your email icon.

  • You have the option of subscribing to “digest” emails which cuts down on the number of emails you receive per day. Instead of getting individual emails as they’re sent you get fewer emails with multiple messages per email. If you do subscribe to the digest and want to be on the ‘taking’ side of freecycling you’ll always be behind since you’re not getting the messages in real-time. In my experience, items tend to go to the first responder.

  • For casual members it’s annoying to always be receiving email from the group when you only participate occasionally. It seems like a really inefficient use of resources to have about 60 emails delivered to my computer, iPhone and iPad each day when I ignore them most of the time.

  • When you post to the group you need to know the correct email address to send to. If it’s not already in your address book you need to search it out. Casual users aren’t going to remember the email address when they only post something once every few weeks.

  • You need to remember the format of the subject line when posting to the group. Frequent users will have this memorized but casuals users aren’t going to remember the subject line format.

  • It’s difficult to include images. The best you can do is upload an image to an image hosting service (normal people know about those, right?) and put a link to it in your email. People reading the message need to select the link which will take them to the image in a different web page or application. This is not a good user experience. For a community based on exchanging physical objects I would think images of those objects would be pretty important.

A quick search of the App Store shows there are better options out there. Yard Sale is one example. It’s a very nicely designed iOS app which facilitates selling and buying things with people around you. You can also list items for free. Images are a central part of the app. This app and would work perfectly for the Alameda Freecycle community except that nobody uses it. For it to be of any use you need a critical mass of users in your neighborhood to be using it. That’s the big problem. How do you get enough people to move over to a better better platform in order to force everyone else to follow along?

It’s a shame that in 2012 we’re still using a glorified listserv for something as important as the freecycling community when much better alternatives are sitting around begging to be used.

Link

Great post. Beautiful sentiment. One way I look at it is like this. Every day my kids are a little bit bigger than they were the day before. Literally. It’s really easy to spend a decade of your life working and justify it by telling yourself you’re providing a better future for your family. But kids go from eight to eighteen in those same ten years and you’re never going to be satisfied with your pay or possessions anyway. A lot of growing up that happens in just a decade. I want to be there for all of it. That’s one reason why I maintain a strict separation between work life and home life. Assuming you have enough to avoid day-to-day financial stress more money doesn’t ensure a happier life. You already have everything you need for a happy life.

Text

Developer Tip: Don’t Paste SQL Results Into Emails

If you’re a developer who has to communicate with other people at all here’s a tip. Do not paste SQL results into emails.

  • The output from the MySQL command line is intended to be displayed in a monospace font so the columns line up neatly. There’s no guarantee your email will be read in a monospace font. It’s very likely it won’t be.

  • It’s going to wrap. For results containing many columns it will wrap a lot and will be unreadable. This does not communicate information.

  • Even if the query results were properly formatted nobody wants to stare at them long enough to interpret the data contained within.

  • It’s lazy. You’re saying to the recipient, “I can’t be bothered to actually answer your question so here’s some database rows. Chew on that.”

Instead, just provide a quick textual summary of what you need to say. Something that succinctly answers the question. If you want to provide a query or two for the recipient to run on their own time that’s fine. But don’t make it a requirement of understanding what you need to say.

Link

Stephen Hackett reviews the PaperMate 1.4b. The black version has been my pen of choice for the past few years. Ultra smooth. Nice dark consistent lines. Nice to see it getting some attention.

Link

One company sees themselves as being accountable to their customers. Almost every other company in the world sees themselves as being accountable to their shareholders.

Quote
"You are blinded by the love of the office you hold."

— Albus Dumbledore

Text

Covering Up Browser Languages

I’ve been a web-developer for over fifteen years. Over the course of those years I’ve learned to trust my instincts. Going with my instincts usually serves me well and going against them usually causes pain. Right now, my instincts are telling me that languages like HAML, SASS, and CoffeeScript are going to cause me more pain than good.

Web browsers use three different languages to render web pages: HTML, CSS, and JavaScript. HTML defines what information appears on a page. CSS determines how information looks on a page. JavaScript dynamically manipulates both HTML and CSS to create a more interactive and visually engaging experience. These languages have been around for a long time and may not compare favorably to the fresh faces of Ruby and Python. Naturally, there is a desire to modernize the browser languages.

HAML aims to make HTML better by eliminating closing tags and reducing the amount of code to type. White space is significant. Indentation matters. The document structure more apparent when working with it.

SASS improves CSS by adding variables, nesting and inheritance. It’s a more programmer-friendly version of CSS.

Finally, CoffeeScript gives JavaScript a more modern syntax which Ruby or Python developers will feel more comfortable with.

However, browsers can’t execute these new languages so they must be compiled to their native counterparts to be useful. I see a few problems with this.

Crowded Headspace

With traditional languages and operating systems I can write C code and pretend that Assembly language doesn’t exist. Assembly language never crosses my mind while I’m writing or debugging code.

However, you cannot pretend HTML, CSS and JavaScript don’t exist. Thousands of books and web sites which teach web development are, of course, written using HTML, CSS and JavaScript. Official documentation and reference sources will always use the native languages. There is absolutely no way you can practically use HAML, SASS and CoffeeScript without also knowing HTML, CSS, and JavaScript. For each native language you work with you’ll have to keep two concepts active in your head and translate between the two as you work.

I don’t think this makes web development any easier. What developers do is complicated enough without adding new languages to the process which aren’t completely necessary.

Compiling Required

HAML, SASS, and CoffeeScript also introduces additional software libraries and steps to the development and deployment process. The “improved language” source files must be converted to their native counterparts. Ruby on Rails 3.1 supports CoffeeScript and SASS by default and adding in HAML support is very easy. But in a less-blessed environment you’re going to have to a significant amount of work yourself.

What if you don’t do 100% of your work in Ruby on Rails? What if you want to experiment with something outside the confines of your regular framework? It often helps to create a simple demo page with bare-bones HTML/CSS/JavaScript when experimenting with a new concept. With native languages you create the files, load the page in your browser and you’re good. With the improved languages you always have compile the native versions yourself or be working in an environment like Ruby on Rails which will do it for you.

Static Sites

I’ve spent most of my career working on “big” sites with dynamic backends written in PHP, Java or Ruby on Rails. However, there are a lot projects for which a static site makes the most sense. These sites exist as static files and Apache (or whatever) serves the files straight-up. It would be unreasonable to have to compile HAML, SASS or CoffeeScript every time I want to change something on a static site.

Debugging

Browsers only deal with native languages. The debugging tools in browsers only deal with native languages. If you’re inspecting a DOM tree you’re going to be looking at HTML. Not HAML. When you’re stepping through JavaScript code it’s going to be actual JavaScript and not CoffeeScript. You to do mental translation between the code you write and the code that matters. You need as much of your brain as possible for actual development and debugging.

Sharing Code/Knowledge

Browser languages are no longer the simple things they were almost twenty years ago when calling HTML a “language” was considered generous. Today, HTML, CSS and JavaScript have advanced to a state where a whole new class of engineers have coalesced around them. Front-end engineers are very important and in very high demand. They think and communicate in native languages. When you need to share code you’re going to do it with HTML, CSS and JavaScript because you don’t know who has bought into the improved languages yet and you want your code and ideas to be as widely useful to as possible. If you want to discuss front-end technology online with other developers you’re going to use native languages because you want to be understood by everybody.

Conclusion

If enough browsers supported the improved languages directly I’d be inclined to make the switch. Maybe they eventually will and HTML, CSS and JavaScript will become the Assembly language of the web. I actually think that would be pretty cool. Until then, I’m sticking with HTML, CSS and JavaScript.

Text

Background Image on a UIView

Here’s a snippet of code you can use to add a background image to any UIView.

Enjoy.

Link

Interesting reading if you’re a UNIX geek. I’ve always wondered what the difference was between bin, sbin, usr/bin and usr/sbin. Turns out it has a lot to do with disk sizes back in 1971.

Link

Well, this looks pretty darn cool!