Blog

When to best use type inference

Type inference can make code much better. It can save you from writing down something that is completely obvious, and thus a total waste of space to write down. For example, type inference is helpful in the following code:

// Type inference
val date = new Date

// No type inference
val date: Date = new Date
It's even better for generics, where the version without type inference is often absurd:

// Type inference
val lengths: List[Int] =
names.map(n => n.length).filter(l => l >= 0)

// No type inference
val lengths: List[Int] =
names.map[Int, List[Int]]((n: String) => n.length).
filter((l: Int) => l >= 0)
When would a type not be "obvious"? Let me describe two scenarios.

First, there is obvious to the reader. If the reader cannot tell what a type is, then help them out and write it down. Good code is not an exercise in swapping puzzles with your coworkers.


// Is it a string or a file name?
val logFile = settings.logFile

// Better
val logFile: File = settings.logFile
Second, there is obvious to the writer. Consider the following example:

val output =
if (writable(settings.out))
settings.out
else
"/dev/null"
To a reader, this code is obviously producing a string. How about to the writer? If you wrote this code, would you be sure that you wrote it correctly? I claim no. If you are honest, you aren't sure what settings.out is unless you go look it up. As such, you should write it this way, in which case you might discover an error in your code:

val output: String =
if (writable(settings.out))
settings.out // ERROR: expected String, got a File
else
"/dev/null"
Languages with subtyping all have this limitation. The compiler can tell you when an actual type fails to satisfy the requirements of an expected type. However, if you ask it whether two types can ever be used in the same context as each other, it will always say yes, they could be used as type Any. ML and Haskell programmers are cackling as they read this.

It's not just if expressions, either. Another place this issue crops up is in collection literals. Unless you tell the compiler what kind of collection you are trying to make, it will never fail to find a type for it. Consider this example:


val path = List(
"/etc/scpaths",
"/usr/local/sc/etc/paths",
settings.paths)
Are you sure that settings.paths is a string and not a file? Are you sure nobody will change that type in the future and then see what type check errors they get? If you aren't sure, you should write down the type you are trying for:

val path = List[String](
"/etc/scpaths",
"/usr/local/sc/etc/paths",
settings.paths) // ERROR: expected String, got a File
Type inference is a wonderful thing, but it shouldn't be used to create mysteries and puzzles. In code, just like in prose, strive to say the interesting and to elide the obvious.
Posted in Blogroll

Ten Good Years

It’s been ten years since we started this thing, and what a long way we’ve come. From a discussion between myself and Mike Little about forking our favorite blogging software, to powering 18% of the web. It’s been a crazy, exciting, journey, and one that won’t stop any time soon.

At ten years, it’s fun to reflect on our beginnings. We launched WordPress on 27th May 2003, but that wasn’t inception. Go back far enough, and you can read a post by Michel Valdrighi who, frustrated by the self-hosted blogging platforms available, decided to write his own software; “b2, a PHP+MySQL alternative to Blogger and GreyMatter.” b2 was easy to install, easy to configure, and easy for developers to extend. Of all the blogging platforms out there, b2 was the right one for me: I could write my content and get it on the web quickly and painlessly.

Sometimes, however, life gets in the way. In 2002, Michel stopped maintaining b2. Over time, security flaws became apparent and updates were needed and, while the b2 community could write patches and fixes, no one was driving the software forward. We were lucky that Michel decided to release b2 under the GPL; the software may have been abandoned, but we weren’t without options. A fork was always a possibility. That was where it stood in January 2003, when I posted about forking b2 and Mike responded. The rest, as they say, is history.

From the very beginning to the present day, I’ve been impressed by the thought, care, and dedication that WordPress’ developers have demonstrated. Each one has brought his or her unique perspective, each individual has strengthened the whole. It would be impossible to thank each of them here individually, but their achievements speak for themselves. In WordPress 1.2 the new Plugin API made it easy for developers to extend WordPress. In the same release gettext() internationalization opened WordPress up to every language (hat tip: Ryan Boren for spending hours wrapping strings with gettext). In WordPress 1.5 our Theme system made it possible for WordPress users to quickly change their site’s design: there was huge resistance to the theme system from the wider community at the time, but can you imagine WordPress without it? Versions 2.7, 2.8, and 2.9 saw improvements that let users install and update their plugins and themes with one click. WordPress has seen a redesign by happycog (2.3) and gone under extensive user testing and redesign (Crazyhorse, Liz Danzico and Jen Mylo, WordPress 2.5). In WordPress 3.0 we merged WordPress MU with WordPress — a huge job but 100% worth it. And in WordPress 3.5 we revamped the media uploader to make it easier for people to get their images, video, and media online.

In sticking to our commitment to user experience, we’ve done a few things that have made us unpopular. The WYSIWYG editor was hated by many, especially those who felt that if you have a blog you should know HTML. Some developers hated that we stuck with our code, refusing to rewrite, but it’s always been the users that matter: better a developer lose sleep than a site break for a user. Our code isn’t always beautiful, after all, when WordPress was created most of us were still learning PHP, but we try to make a flawless experience for users.

It’s not all about developers. WordPress’ strength lies in the diversity of its community. From the start, we wanted a low barrier to entry and we came up with our “famous 5 minute install”. This brought on board users from varied technical background: people who didn’t write code wanted to help make WordPress better. If you couldn’t write code, it didn’t matter: you could answer a question in the support forums, write documentation, translate WordPress, or build your friends and family a WordPress website. There is space in the community for anyone with a passion for WordPress.

It’s been wonderful to see all of the people who have used WordPress to build their home on the internet. Early on we got excited by switchers. From a community of tinkerers we grew, as writers such as Om Malik, Mark Pilgrim, and Molly Holzschlag made the switch to WordPress. Our commitment to effortless publishing quickly paid off and has continued to do so: the WordPress 1.2 release saw 822 downloads per day, our latest release, WordPress 3.5, has seen 145,692 per day.

I’m continually amazed by what people have built with WordPress. I’ve seen musicians and photographers, magazines such as Life, BoingBoing, and the New York Observer, government websites, a filesystem, mobile applications, and even seen WordPress guide missiles.

As the web evolves, WordPress evolves. Factors outside of our control will always influence WordPress’ development: today it’s mobile devices and retina display, tomorrow it could be Google Glass or technology not yet conceived. A lot can happen in ten years! As technology changes and advances, WordPress has to change with it while remaining true to its core values: making publishing online easy for everyone. How we rise to these challenges will be what defines WordPress over the coming ten years.

To celebrate ten years of WordPress, we’re working on a book about our history. We’re carrying out interviews with people who have involved with the community from the very beginning, those who are still around, and those who have left. It’s a huge project, but we wanted to have something to share with you on the 10th anniversary. To learn about the very early days of WordPress, just after Mike and I forked b2 you can download Chapter 3 right here. We’ll be releasing the rest of the book serially, so watch out as the story of the last ten years emerges.

In the meantime, I penned my own letter to WordPress and other community members have been sharing their thoughts:

You can see how WordPress’ 10th Anniversary was celebrated all over the world by visiting the wp10 website, according to Meetup we had 4,999 celebrators.

To finish, I just want to say thank you to everyone: to the developers who write the code, to the designers who make WordPress sing, to the worldwide community translating WordPress into so many languages, to volunteers who answer support questions, to those who make WordPress accessible, to the systems team and the plugin and theme reviewers, to documentation writers, event organisers, evangelists, detractors, supporters and friends. Thanks to the jazzers whose music inspired us and whose names are at the heart of WordPress. Thanks to everyone who uses WordPress to power their blog or website, and to everyone who will in the future. Thanks to WordPress and its community that I’m proud to be part of.

Thank you. I can’t wait to see what the next ten years bring.

Final thanks to Siobhan McKeown for help with this post.

Posted in Blogroll

The Next 10 Starts Now

All around the globe today, people are celebrating the 10th anniversary of the first WordPress release, affectionately known as #wp10. Watching the feed of photos, tweets, and posts from Auckland to Zambia is incredible; from first-time bloggers to successful WordPress-based business owners, people are coming out in droves to raise a glass and share the “holiday” with their local communities. With hundreds of parties going on today, it’s more visible than ever just how popular WordPress has become.

Thank you to everyone who has ever contributed to this project: your labors of love made this day possible.

But today isn’t just about reflecting on how we got this far (though I thought Matt’s reflection on the first ten years was lovely). We are constantly moving forward. As each release cycle begins and ends (3.6 will be here soon, promise!), we always see an ebb and flow in the contributor pool. Part of ensuring the longevity of WordPress means mentoring new contributors, continually bringing new talent and fresh points of view to our family table.

I am beyond pleased to announce that this summer we will be mentoring 8 interns, most of them new contributors, through Google Summer of Code and the Gnome Outreach Program for Women. Current contributors, who already volunteer their time working on WordPress, will provide the guidance and oversight for a variety of exciting projects  this summer. Here are the people/projects involved in the summer internships:

  • Ryan McCue, from Australia, working on a JSON-based REST API. Mentors will be Bryan Petty and Eric Mann, with a reviewer assist from Andrew Norcross.
  • Kat Hagan, from the United States, working on a Post by Email plugin to replace the core function. Mentors will be Justin Shreve and George Stephanis, with an assist from Peter Westwood.
  • Siobhan Bamber, from Wales, working on a support (forums, training, documentation) internship. Mentors will be Mika Epstein and Hanni Ross.
  • Frederick Ding, from the United States, working on improving portability. Mentors will be Andrew Nacin and Mike Schroder.
  • Sayak Sakar, from India, working on porting WordPress for WebOS to Firefox OS. Mentor will be Eric Johnson.
  • Alex Höreth, from Germany, working on  adding WordPress native revisions to the theme and plugin code editors. Mentors will be Dominik Schilling and Aaron Campbell, with a reviewer assist from Daniel Bachhuber.
  • Mert Yazicioglu, from Turkey, working on ways to improve our community profiles at profiles.wordpress.org. Mentors will be Scott Reilly and Boone Gorges.
  • Daniele Maio, from Italy, working on a native WordPress app for Blackberry 10. Mentor will be Danilo Ercoli.

Did you notice that our summer cohort is as international as the #wp10 parties going on today? I can only think that this is a good sign.

It’s always a difficult process to decide which projects to mentor through these programs. There are always more applicants with interesting ideas with whom we’d like to work than there are opportunities. Luckily, WordPress is a free/libre open source software project, and anyone can begin contributing at any time. Is this the year for you? We’d love for you to join us as we work toward #wp20. ;)

Posted in Blogroll

Got My Google Glass

On Thursday I got my Google Glass Explorer Edition unit. I’m not sure what I was expecting, but it is a really awesome device for asking Google simple questions, mapping / directions, and taking pictures or movies while I’m on my bike. It doesn’t have many apps; the native SDK isn’t available yet, but there are some interesting web APIs you can use called Google Glassware.

The device has an ok camera, ok battery life, and ok WiFi and Bluetooth. The projector screen looks reasonable but isn’t very high resolution. Along my right temple there is a touch sensitive surface. There isn’t a speaker, but it uses a bonefone for sound output (by vibrating against the back of my ear). The mic can pick put other people shouting commands at me, but it is only in voice command mode very VERY briefly so having unwanted input is not a huge concern.

Glass runs Android Ice Cream Sandwich 4.0.4. All of the local applications appear to be standard apks. You can take download them to a PC using adb, uncompress them, and examine their structure. The various Dalvik bytecode inspectors still work correctly and there doesn’t seem to be anything special going on under the hood as far as software goes.

Using Glass is somewhat of a mixed bag. The voice commands are rather limited; however, the voice recognition and synthesis are VERY good. Taking a picture, recording a video, starting a call, and performing a search are nearly instant. Getting directions, making a call, sending a message, and starting a hangout tend to be good if you are on WiFi but you are at your carrier’s mercy when you are tethered to your phone. Overall the voice controls are impressive where they exist.

If you wish to do other things (ex, read a notification, configure your device, share a photo), you will probably have to use the touch controls on your temple. They are limited (you have single finger swipe left, swipe right, swipe down, and tap gestures), but once you get used to them you can navigate the device quite well.

A lot has been made about the social implications of Glass (mostly in the press which has had a nice babble head quality about the device). In general the reactions I have had have been good. Lots of people have come up to me to ask about it and get a quick demo. No body has asked me to take it off and for people who havn’t heard of Glass saying “It’s a computer” generally satisfies them. I still feel self conscious about it when I go out with it, and I’m not used to having strangers ask me questions about my tech. At the very least it has been good practice for public speaking.

From a developer’s point of view I adore this device. It is VERY different from what I am used to in terms of affordances and capabilities. Being able to have a very quick, unobtrusive, but intimate moment with my user is completely new. However, the capabilities in terms of amount of content I can deliver and receive is limited. This is a Jane. You ask it to tell a server elswhere to do something on your behalf and wait for the response. It has sensors to collect all of the necessary information it may need. Then it is my job to take that information and use my server resources to create a good response and deliver it to the user (quickly).

Currently, there are several companies making Glassware applications for the device. The New York Times has a nice service you can subscribe to. Twitter released an application, and there are some third party Facebook apps as well. Google has been on a regular update cycle for the device so it should have extra functionality rolled out over the next few months. Finally there are several I/O sessions about the device which should encourage more development.

In addition to the device itself, there is a companion Android application which helps with configuring, tethering, and demoing the device. The app includes a screen catcher so people can see what you see. There is also a web app which is used for installing services, managing your shared contacts, and viewing information about your device. Finally there is a web forum for connecting with other Glass Explorers.

I’m researching the device, its software, and its services. I am planning on making some hello world style applications and advocating the technology. I don’t know if this will change computing or consumption, but I hope it at successfully and popularly augments it. We have been promised wearable and ubiquitous computing for a while and Glass is the next step in this general evolution.

Posted in Blogroll

WordPress 3.6 Beta 3

WordPress 3.6 Beta 3 is now available!

This is software still in development and we really don’t recommend that you run it on a production site — set up a test site just to play with the new version. To test WordPress 3.6, try the WordPress Beta Tester plugin (you’ll want “bleeding edge nightlies”). Or you can download the beta here (zip).

Beta 3 contains about a hundred changes, including improvements to the image Post Format flow (yay, drag-and-drop image upload!), a more polished revision comparison screen, and a more quote-like quote format for Twenty Thirteen.

As a bonus, we now have oEmbed support for the popular music-streaming services Rdio and Spotify (the latter of which kindly created an oEmbed endpoint a mere 24 hours after we lamented their lack of one). Here’s an album that’s been getting a lot of play as I’ve been working on WordPress 3.6:

Plugin developers, theme developers, and WordPress hosts should be testing beta 3 extensively. The more you test the beta, the more stable our release candidates and our final release will be.

As always, if you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. Or, if you’re comfortable writing a reproducible bug report, file one on the WordPress Trac. There, you can also find a list of known bugs and everything we’ve fixed so far.

We’re looking forward to your feedback. If you find a bug, please report it, and if you’re a developer, try to help us fix it. We’ve already had more than 150 contributors to version 3.6 — it’s not too late to join in!

Posted in Blogroll

Toggle sidebar in Sublime Text

The more I use Sublime Text the more I like it. 

One thing that is missing (at least in the Linux version) is a shortcut to toggle the side bar.  The Mac version used to use "ctrl+s", but that's what I associate with saving a file.  I added a shortcut for "ctrl+b"; "b" for "bar" :

{ "keys": ["ctrl+b"], "command": "toggle_side_bar" }

To add this choose Preferences -> Key Bindings User

Be sure to add a comma to the line above as well.
Posted in Blogroll

Siently add a management user in JBoss EAP6/AS7

Adding a management user is required and simple to doin EAP6.  AS7 is the same even though its a dead branch.

If you need to add the user silently simply add the "--silent=true" flag to the command :


jboss-eap-6.0/bin/add-user.sh --silent=true <username> <password> [ManagementRealm]
Posted in Blogroll

WordPress 3.6 Beta 2

WordPress 3.6 Beta 2 is now available!

This is software still in development and we really don’t recommend that you run it on a production site — set up a test site just to play with the new version. To test WordPress 3.6, try the WordPress Beta Tester plugin (you’ll want “bleeding edge nightlies”). Or you can download the beta here (zip).

The longer-than-usual delay between beta 1 and beta 2 was due to poor user testing results with the Post Formats UI. Beta 2 contains a modified approach for format choosing and switching, which has done well in user testing. We’ve also made the Post Formats UI hide-able via Screen Options, and set a reasonable default based on what your theme supports.

There were a lot of bug fixes and polishing tweaks done for beta 2 as well, so definitely check it out if you had an issues with beta 1.

Plugin developers, theme developers, and WordPress hosts should be testing beta 2 extensively. The more you test the beta, the more stable our release candidates and our final release will be.

As always, if you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. Or, if you’re comfortable writing a reproducible bug report, file one on the WordPress Trac. There, you can also find a list of known bugs and everything we’ve fixed so far.

We’re looking forward to your feedback. If you find a bug, please report it, and if you’re a developer, try to help us fix it. We’ve already had more than 150 contributors to version 3.6 — it’s not too late to join in!

Posted in Blogroll

Summer Mentorship Programs: GSoC and Gnome

As an open source, free software project, WordPress depends on the contributions of hundreds of people from around the globe — contributions in areas like core code, documentation, answering questions in the support forums, translation, and all the other things it takes to make WordPress the best publishing platform it can be, with the most supportive community. This year, we’re happy to be participating as a mentoring organization with two respected summer internship programs: Google Summer of Code (GSoC) and the Gnome Outreach Program for Women.

Google Summer of Code

GSoC is a summer internship program funded by Google specifically for college/university student developers to work on open source coding projects. We have participated in the Google Summer of Code program in the past, and have enjoyed the opportunity to work with students in this way. Some of our best core developers were GSoC students once upon a time!

Our mentors, almost 30 talented developers with experience developing WordPress, will provide students with guidance and feedback over the course of the summer, culminating in the release of finished projects at the end of the program if all goes well.

Students who successfully complete the program earn $5,000 for their summer efforts. Interested, or know a college student (newly accepted to college counts, too) who should be? All the information you need about our participation in the program, projects, mentors, and the application process is available on the GSoC 2013 page in the Codex.

Gnome Outreach Program for Women

It’s not news that women form a low percentage of contributors in most open source projects, and WordPress is no different. We have great women in the contributor community, including some in fairly visible roles, but we still have a lot of work to do to get a representative gender balance on par with our user base.

The Gnome Outreach Program for Women aims to provide opportunities for women to participate in open source projects, and offers a similar stipend, but there are three key differences between GSoC and Gnome aside from the gender requirement for Gnome.

  1. The Gnome program allows intern projects in many areas of contribution, not just code. In other words, interns can propose projects like documentation, community management, design, translation, or pretty much any area in which we have people contributing (including code).
  2. The Gnome Outreach Program for Women doesn’t require interns to be college students, though students are definitely welcome to participate. This means that women in all stages of life and career can take the opportunity to try working with open source communities for the summer.
  3. We have to help raise the money to pay the interns. Google funds GSoC on its own, and we only have to provide our mentors’ time. Gnome doesn’t have the same funding, so we need to pitch in to raise the money to cover our interns. If your company is interested in helping with this, please check out the program’s sponsorship information and follow the contact instructions to get involved. You can earmark donations to support WordPress interns, or to support the program in general. (Pick us, pick us! :) )

The summer installment of the Gnome Outreach Program for Women follows the same schedule and general application format as GSoC, though there are more potential projects since it covers more areas of contribution. Women college students interested in doing a coding project are encouraged to apply for both programs to increase the odds of acceptance. All the information you need about our participation in the program, projects, mentors, and the application process is available on the Gnome Outreach Program for Women page in the Codex.

The application period just started, and it lasts another week (May 1 for Gnome, May 3 for GSoC), so if you think you qualify and are interested in getting involved, check out the information pages, get in touch, and apply… Good luck!

Google Summer of Code 2013 Information
Gnome Summer Outreach Program for Women 2013 Information

Posted in Blogroll

WordPress 10th Anniversary Tees

WordPress 10th Anniversary logoIn honor of the upcoming 10th anniversary celebrations, we’ve put a special 10th anniversary tshirt in the swag store at cost — $10 per shirt plus shipping. They’ll be on sale at this price until the anniversary on May 27, and they’ll start shipping out the week of April 29.

Some people who are planning parties or who organize meetups are already talking about doing group orders to save on shipping costs, which is a great idea — just make sure you allow enough shipping time. If you’re not sure if the tees could make it to you in time on your side of the world, use the contact options at the bottom of the store page to ask about shipping times. If they can’t reach you in time and you want to have a local printer do some for your group, we’ll post the vector file on the wp10 site within the next week (and this post will get updated accordingly).

The shirts are available in black or silvery gray. Why silvery gray? Because of trivia: the traditional gift for 10th anniversaries is tin or aluminum. :)

Silver and Black tshirts with WordPress 10th anniversary logo on them

Posted in Blogroll
AJUG Meetup

Faster than C? Parsing Node.js Streams!

Thursday, June 13, 2013

In 2010 I wrote the first MySQL driver for node.js. I did it in pure JavaScript. It was fast. It was fun. A few month later, node addons using libmysql showed up in npm. They were much faster. It sucked. In 2012 I had enough and went back to to the drawing board resulting in a much faster parser. This talk will introduce you to the art of high performance work in JavaScript.
Location:

Holiday Inn Atlanta-Perimeter/Dunwoody 4386 Chamblee Dunwoody Road, Atlanta, GA (map)

AJUG Tweets

  • The RSS feed for this twitter account is not loadable for the moment.

/ Follow @ghillert on twitter.

AJUG Blog

  • When to best use type inference

    Type inference can make code much better. It can save you from writing down something that is completely obvious, and thus a total waste of space to write down. For example, type inference is helpful in the following code:


    // Type inference
    val date = new Date

    // No type inference
    val date: Date = new Date
    It's even better for generics, where the version without type inference is often absurd:

    // Type inference
    val lengths: List[Int] =
    names.map(n => n.length).filter(l => l >= 0)

    // No type inference
    val lengths: List[Int] =
    names.map[Int, List[Int]]((n: String) => n.length).
    filter((l: Int) => l >= 0)
    When would a type not be "obvious"? Let me describe two scenarios.

    First, there is obvious to the reader. If the reader cannot tell what a type is, then help them out and write it down. Good code is not an exercise in swapping puzzles with your coworkers.


    // Is it a string or a file name?
    val logFile = settings.logFile

    // Better
    val logFile: File = settings.logFile
    Second, there is obvious to the writer. Consider the following example:

    val output =
    if (writable(settings.out))
    settings.out
    else
    "/dev/null"
    To a reader, this code is obviously producing a string. How about to the writer? If you wrote this code, would you be sure that you wrote it correctly? I claim no. If you are honest, you aren't sure what settings.out is unless you go look it up. As such, you should write it this way, in which case you might discover an error in your code:

    val output: String =
    if (writable(settings.out))
    settings.out // ERROR: expected String, got a File
    else
    "/dev/null"
    Languages with subtyping all have this limitation. The compiler can tell you when an actual type fails to satisfy the requirements of an expected type. However, if you ask it whether two types can ever be used in the same context as each other, it will always say yes, they could be used as type Any. ML and Haskell programmers are cackling as they read this.

    It's not just if expressions, either. Another place this issue crops up is in collection literals. Unless you tell the compiler what kind of collection you are trying to make, it will never fail to find a type for it. Consider this example:


    val path = List(
    "/etc/scpaths",
    "/usr/local/sc/etc/paths",
    settings.paths)
    Are you sure that settings.paths is a string and not a file? Are you sure nobody will change that type in the future and then see what type check errors they get? If you aren't sure, you should write down the type you are trying for:

    val path = List[String](
    "/etc/scpaths",
    "/usr/local/sc/etc/paths",
    settings.paths) // ERROR: expected String, got a File
    Type inference is a wonderful thing, but it shouldn't be used to create mysteries and puzzles. In code, just like in prose, strive to say the interesting and to elide the obvious.