The idea was actually fueled by my love for Gumroad (and a bit of jealousy).  As the story goes, Sahil Lavingia had this awesome idea for a startup.  So, he hacked away for a couple nights, and came to the point that he was ready to show the world an MVP.  If I understand it correctly, he had the domain gumroad.com sitting in a stockpile somewhere, and it just happened to be abstract enough to work.  Man, I wish I was that cool.

Speaking of Sahil and Gumroad, did you hear that he recently closed a $7.7 million round of funding?  Congrats, man.

If you’re interested, the source for this app can be found on Github, and is written in Node.js.  There’s a little portion that I wrote in PHP and haven’t shared, but it’s incredibly simple.  The only important part is that it’s calling from a database of 200,000 possible words (that I may open source at some point).

Trying to keep to that standard, I find myself writing the same lines over and over to encode my objects in JSON before returning them (this is generally returning to an API call).  I wrote a quick little script to automatically detect if I’m trying to respond with an object.  Here goes:

//This probably goes somewhere else, but for testing purposes...

var http = require('http');
//Scope this however is ideal for your environment

var hold = http.ServerResponse.prototype.end;

http.ServerResponse.prototype.end = function() {

if(typeof(arguments[0]) === "object") {

arguments[0] = JSON.stringify(arguments[0]);

}
hold.apply(this, arguments);

};
http.createServer(function(req, res) {

//And build your objects however you like. No special format - just your data.

var dat = {

a: "This",

b: "is",

c: "some",

d: "data!"

};
res.end(dat);

}).listen(1234);

Pretty simple little addition. As I mentioned in the code, you may want to scope the `hold` variable a little different, depending on your environment. Also – this is important – this will NOT work if you are using res.write(). This generally isn’t the case if you are formatting in JSON, because it’s hard to chunk an object, but if you are fancy like that you will need to make some modifications. It should be simple enough to override the res.write() function in a similar way as I did with res.end().

Additionally, a system like this can be used for pretty much any pre-write hook.  It’s not always a good idea to override the pre-defined functions in Node.js (it’s hard to maintain), but occasionally that makes the most sense.  If you have different functionality you’d like to add, just replace the http.ServerResponse.prototype.end portion with whatever you need to do.

As a bit of a disclaimer, I’m pretty crazy about Node.js.  Whether you think that’s a justified insanity is up to you, but I certainly think it’s worth at least looking in to.  Much of the world is trying to avoid Node.js – it’s new, it’s a little confusing, it’s all javascript, and it requires a lot of work to move from something like a LAMP stack to a full Node.js server.  Here’s the thing, though: I don’t want you to leave LAMP.  Obviously there’s a lot of benefits to getting away from Apache/PHP, but they’re not requirements to use Node.js for real-time data.  The solution I’m presenting simply uses a lightweight Node.js server on the side that accepts HTTP requests and passes them on to the frontend.  Send your requests from PHP, python, cURL, or some other awful language, and you’ll get exactly the same functionality.

The backbone of this system is socket.io, which I consider to be the holy grail of Node.js in web development.  Socket.io is a system that utilizes web sockets to pass data back and forth between a server and a client in real time.  Because it’s based on web sockets, it doesn’t require a new connection to be made every time data needs to be sent – it keeps a connection open and just listens for whenever the other side starts talking.  The bright side to using Socket.io to handle your web sockets is that they’ve built in some wonderful graceful degradation for older browsers that might not support web sockets.

So here’s how we start on the server.  Essentially we’re just starting up a Socket.io server and an HTTP server.  When that HTTP server receives data it pinpoints the user to send it to, and then sends it via Socket.IO.

var http = require('http');

var socketio = require('socket.io');

var qs = require('querystring');
var destinations = {}; //This will hold all of our registered clients
var app = http.createServer(function(req, res) {

    var postData = "";
    req.on('data', function(chunk) {

        postData += chunk; //Get the POST data

    });
    req.on('end', function() {

        var POST = qs.parse(postData);
        if(typeof(destinations[POST.destination]) !== "undefined") {

            destinations[POST.destination].emit("push", {

                data: POST.data //Send it!

            });

        }

    });
    res.end();

}).listen(8080);  //Use a non-standard port so it doesn't override your Apache
var io = socketio.listen(app); //Attach socket.io to port 8080
io.sockets.on('connection', function(socket) {

    socket.on('register', function(data) { //Client registers so we know where to send

        destinations[data.id] = socket;

    });

});

That’s it!  Your Node.js server is ready to start passing data between your frontend and the backend.  All you need to do is include socket.io on the frontend and register with the server.

<script type="text/javascript" src="http://www.mydomain.com:8080/socket.io/socket.io.js"></script>

<script type="text/javascript">

var socket = io.connect("http://www.mydomain.com:8080");
socket.on('push', function(data) {

	//Do something with the data

});
socket.emit('register', {

	id: 12345 //Use a unique ID here.  I'm using my session ID

});
</script>

You’re good to go.  Now to pass data all you have to do is make an HTTP request to the server running Node.js on port 8080.  The request will need two POST parameters:

• destination -> The ID of the user that should receive the data.  This should match the ID that you sent via Socket.io on the frontend (which is why I’m using the session ID)
• data -> The data to send to the user.  I generally encode this in JSON, but you can do whatever you want

Swift really has everything that you’d want in a portfolio.  It’s run on CSS3 and HTML5, so you can flash those buzz words around all you want.  Along with some of the tricks provided by CSS3, it utilizes jQuery to make it fully responsive so it looks great on every device.  It’s also got some crazy navigation features that might rock your world.  I’ll put some screenshots below, but you might just be better off checking out the demo.

The Nav Pane

Fact: Pretty much every website out there does the same thing for navigation.  They’ve either got some buttons on the header up top, or some buttons on the sidebar on the left.  BORING.  Swift comes with a full-page nav pane that you can customize with as many icons as you’d like.  Don’t worry – if you add too many our fancy CSS3 will make sure that it flows pleasantly down the page.

Look kind of boring?  Like how in the world do you know what those icons mean?  Just roll over them, and we’ll tell you (if you don’t go blind from our beautiful tooltip first).

The Content

You’ve played this theme game before.  Some guy who think he knows it all is going to give you a pretty little textbox and tell you that’s where you put your content.  Well that sucks, because Mr. know-it-all doesn’t really know how you want your content to look.  I’m not a know-it-all, so I’m gonna let you code-it-all.  That’s right, with Swift you get to write in your own HTML so things will look exactly how you want them.  Don’t be afraid – we’ll provide you with some sample HTML if you’re not savvy enough to write your own yet.

Hold up – I’ve read your mind again.  You’re currently thinking, “But Joe, these super long one-page websites suck!  It takes forever for me to navigate around and view all the content!”  I hear ya – they do suck.  That’s why Swift keeps the navigation always at your fingertips with the home button (really – check this one out in the demo.  It’s mind-blowing).

Now I’ve been considering what I should sell this for….  What do you think?  $1 million dollars?  No, no, I couldn’t possibly go higher than that.  Well, here’s the deal: I like you.  Really, I like you so much, I’m going to give you this theme for only $10!  That’s right – head over to Gumroad ASAP to pick up the Swift Portfolio Theme for just $10.

To be clear, I’m still rooting for Google.   Oracle quoted Andy Rubin in their opening statements:

“Finally, SUN has a different license for its library for SE and ME. The SE library is LGPL, ME library is GPL. That means anything that links with the ME library gets infected. And the SE library is not optimized for embedded systems.  Sun chose GPL for this exact reason so that companies would need to come back to them and take a direct license and pay royalties.”

This is a pretty disgraceful way to use an open source license – OSS isn’t about making a profit, it’s about innovating as a developer community.  Ironically, the same thing applies to the copyright and patent system that are now so abused.  While Oracle may have very valid points in this lawsuit, I certainly believe Google is paving the road of innovation with Android, and will hold my respect whichever way the case goes.

In case you’re not familiar with the Google-vs-Oracle case, here’s a bit of back story.  Sun (now owned by Oracle) wrote an incredible piece of software called Java Runtime Environment (JRE), which is best known for its powerful Java Virtual Machine (JVM).  The JVM allowed developers to write code in a single language and run it on any platform (coined “Write Once, Run Anywhere” by Sun).  This was an incredible innovation, and added some great efficiencies for developers whose markets were cross platform.  Along with the JVM, Java has another critical piece: the Java API.  The API is the portion that is commonly (and somewhat incorrectly) called the Java programming language.  In reality, the Java API is just like any other API – it’s an interface supplied by Sun so that developers can interact with the JVM.

In functionality, the Java API behaves quite similarly to a standard programming language, but differs in how it compiles.  Standard languages like C compile down to assembly language, and is processed directly from there.  Java, however, compiles down into a type of bytecode, and that bytecode is again compiled by a just-in-time complier built into the JVM.  This is the crucial piece that makes Java an API, instead of a standard programming language.  Java is just an interface  which people can use to communicate with the JVM.

This is Google’s fatal flaw.  Google is trying to argue with Oracle that they can’t copyright a programming language.  I believe they will successfully win that argument, and for good reason.   Can you imagine a world where C could have been copyrighted?  Unfortunately, Java is not a programming language.  Java is an interface for interacting with a piece of software (the JVM).  Google was intentional about not wording their argument as such, because I believe it’s very clear that they could not win.  Under that definition, there is an incredibly large amount of APIs out there that are necessarily copyrighted.  Flip this on its head, and imagine if Google had to open up their Customer Search API.  Not only would they lose one of their major revenue sources (because they couldn’t license it), but their entire structure would break down because the world would have a clear view into how they score their search results.

I guess at the end of the day I’m torn.  Google is mostly in the right, here – they’re using Java in an innovative way and they’ve created a wonderful developer platform with Android, but on the other hand they’re clearly stealing.  I would hate to see Oracle win this case, because I believe they decrease the flexibility in the tech sector on many fronts, but I’m also afraid of the implications of APIs not being copyrightable.

The downside to all the magic in the CSS3 spec is that much of  it isn’t available in the leading browsers yet.  So, with that said, take what I’m about to post with a grain of salt.  It won’t work in every browser (actually, currently, it only officially works in Chrome).

I’ve put together a CSS3-based UI set that can be easily applied to any input element just by adding a class.  No weird HTML structures, no javascript, and no images.  Just add a class, and let CSS3 do the rest.  The set is certainly pretty young at this point – much of the design is just a proof of concept – but I intend to build in enhancements over time.  Also, my general design skills are awful (terrible) (disgusting), so don’t expect an award-winning look.

Anyways, here’s a glimpse of what it looks like, and you can also check out this demo.

Also, the source for this icon set can be found on Github.

Note:  Upon further research, it turns out I didn’t fully understand the CSS3 spec for pseudo elements.  Apparently elements that are “void”, or don’t have any content, do not officially support the :after and :before meta tags.  Much of this UI set depends on that, so it will only work in Chrome in its current state.  I will think of a smarter way to do this, refactor, and update here when it’s ready for prime time.  Sorry!

The problem with being me and wanting to have a website is that  - although I’ve got the chops to make things happen in CSS – I haven’t got an ounce of creativity in me.  The majority of what I do and love is backend design, and the frontend design is in very little snippets, like jQuery plugins.  Faced with the task of making an entire website flow together and look nice, I pretty much didn’t know where to start.

Then I had a brilliant idea.  I’ll just look at all the other awesome web designers I know, find what I like about their portfolio sites, and find a way to stitch all that together into my new site.  That’s how everyone does it, right?  Stealing Being inspired by other designs is how everyone does it!  It worked out wonderfully.  I actually designed about five different versions of Wegner Design that I thought were fantastically beautiful, but eventually scrapped them because they weren’t getting across the point I was trying to make.

The problem was that all the designers I was looking at were career designers.  When they drive traffic to their site, they’re looking to show off what they’ve done, and convince people that having a similarly pretty website is going to make them major cash.  The designers I was using for inspiration were looking to drive customers to their site.  I’m not.  As I mentioned before, whenever I am faced with a design task, I generally end up screaming profanities at my monitor.  I don’t want to sell things to my users, so I shouldn’t design that way.

That’s why everything you see right now is either black or white.  I’m not trying to wow you with some cool stitched border, or my awesome textured background, or my knack for typography (none of which I could actually wow you with).  I want you to come to Wegner Design to learn something.  On the homepage, I’m trying to quickly show my users where my skills are as a developer, and whether or not I would be a good fit for their project.  On the blog, I’m trying to share the knowledge that I’ve picked up as I dive into this industry.  Knowing that, I’ve pushed everything else out of the way, and just shown you what’s important.

The results?  No one is clicking through from the homepage to the blog.  No one is moving from the blog to the homepage.  I’m not getting more followers on my twitter, and – as far as I know – I haven’t won any design awards.  Good!  That’s not the point!  If those things were happening, that means I missed the point, and am targeting my site to the wrong goal.  What is happening, though, is that my average time on page is increasing, people are sharing my articles more often, and people are reading more posts every time they view the site.  Best of all, there’s been a massive increase of return readers, who have been able to get past the design and read into the meat of what I post.

I write all this, because I think that many of my readers are in similar spots.  The things I write aren’t generally design focused, so I would image you aren’t either.  When you’re designing your next website, keep in mind that a pretty design isn’t really what matters.  What matters is that you’re serving your users content in a way that effectively communicates your intentions.

View the demo, here!

At the very base usage, all you need is jQuery and an image.  The plugin is smart enough to figure out the size and position of the image you’re working with, and it automatically defaults to make a 10×10 grid over your image.  To get it running at the very base level, your code should look like this.

<html>
<head>
    <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
    <script type="text/javascript" src="jquery.imageTile.js"></script>
    <script type="text/javascript">
         $(window).load(function() {
             $("#image").imageTile();
         });
    </script>
</head>
<body>
    <img src="image.jpg" id="image" />
</body>
</html>

That will put a 10×10 grid of white tiles over your image, and randomly fade them in and out.  It’s a pretty cool effect, and just the simple base like that should work in most cases.  However, I’ve built in some options so that you can override the defaults.  The options are:

• rows -> Integer, the number of rows in the grid.  Defaults to 10
• columns -> Integer, the number of columns in the grid.  Defaults to 10
• animateTime -> Integer or String, the time for the fade effect to finish on each tile.  This accepts a millisecond value, or a jQuery timing string such as “slow”.  Defaults to 800
• newTilesTime -> Integer, how often new tiles will be chosen to fade, in milliseconds.  Defaults to 400
• tilesAtATime -> Integer, the number of tiles to fade at the same time.  Defaults to 5
• backgroundColor -> String, the color of the tiles.  Accepts any valid CSS value, such as “white” or “#C1C1C1″.  Defaults to “white”
• className -> String, the class name to give the <div> that will be created over the image.  Defaults to jquery_tile_div
• maxOpacity -> Integer, the maximum opacity you want applied to any tile

And to load in those options, you simply modify your javascript to look like this:

$("#image").imageTile({
    rows: 5,
    columns: 10,
    animationTime: 600,
    newTilesTime: 300,
    tilesAtATime: 10,
    backgroundColor: "blue",
    className: "dontOverrideTiles",
    maxOpacity: 0.4

});

And that’s it!  The source is hosted on Github, so feel free to grab it from there, make any changes, or simply look at it and find all the awful parts of my code.  If you have any issues or ideas, feel free to leave them in the comments or on the Github issue tracker.

View the demo, here!

Raise your hand if you’ve ever submitted something via a web form.  Hopefully everyone has their hand raised.  If not, scroll down and leave a comment, then come back and raise your hand.  OK – put your hands down.  The obvious statement here is that pretty much everyone uses web forms, and everyone uses them because they’re so easy.  Put in a couple lines of HTML, handle the $_POST variables in PHP, and let the browser do the rest.  It’s a beautiful thing – at least until you need to send data from a script.

The usual scenario is that an API will offer a standard cURL interface, so you can just use simple cURL syntax for uploading from a script.  In DownJS’s cases, though, the API we’re using for storing the javascript files requires a multipart/form-data formatted request.  This requires all kinds of crazy syntax about Content-Types and Content-Length, and then some weird gibberish stuff called “boundaries”.  And, for heaven’s sake, don’t put a \r\n in the wrong place!  Even after you figure out the crazy formatting, there’s still one big issue that needs to be solved – multipart/form-data (I’m going to call them MFD from now on) requests require an accurate Content-Length header.  This means that you normally would have to save the file to the local disk, read it into memory and tack it on to the end of your POST string, check the length, and then send out the entire thing in the HTTP request.  Unfortunately, I don’t have that kind of memory that I can play with, so a better solution was needed.

Enter Multipost.  Multipost is a Node.js modules that allows you to cut out all the gibberish involved in MFD requests, and additionally allows you to pipe files directly over HTTP, rather than loading them into memory beforehand.  The idea is that you write some standard javascript syntax, and we handle the mess and send off the request in the most efficient manner.  You can check out the source as well as some documentation on the Github page, and you can easily install Multipost via NPM.

Multipost is brand new, and relatively untested.  I don’t necessarily encourage you to use it in a production environment (although, we are at DownJS), until you’ve thoroughly tested it in your environment.  If you find any issues,  please drop them on the issue tracker, and I’ll fix them as quickly as I can.

Big thanks to onteria for this wonderful post that guided me through formatting MFD requests.

I’ve known about Gumroad for quite some time now, and I’ve always dismissed it with the thought that “I don’t have anything I can sell”.   Gumroad was a product built for the creative type – graphic designers, poets, musicians.  Even the example product was an awesome icon that I could never dream of designing.  The more I think about it, though, the more I realize that that’s simply not true.  Perhaps all of the examples that Gumroad provides are artsy fartsy, but why couldn’t I have zipped up node-session, and sold it for $2?  I still could have open sourced it, but I could have used Gumroad as a donation platform (think free-as-in-beer, but free-as-in-coke because I’m not 21).

That’s the beautiful thing about the internet.  Chances are that if you’re reading this blog, you’re not one of those people that just consumes what the internet has to offer – you’re a producer.  Whether you do graphic design or you churn out awesome javascript plugins, you’re producing something, and you mine as well make money from it.  It used to be that you had to jump through all kinds of hoops in order to sell anything online – Gumroad is disrupting that standard in a massive way.  You probably haven’t thought of it yet, but now that the barrier to entry is simply an email address, what are you doing that you can sell?

Now Sahil just needs to take me up on my idea to integrate Gumroad and Square, and then he can finally take over the world.  (Seriously, think about it!  Swipe your card, and get sent a link to download node-session!)