samholmes

So my birthday is coming up next month on May 5th, and I had this idea to publish a bitcoin address that would act as a birthday fund. I will use the funds to throw a little party with friends and family for my 22nd birthday!

So feel free to wish me a happy birthday! I appreciate your generosity, and I look forward to seeing how this goes. Thanks! :)

1PtieW8G2KA1CoENFayk1JxJEwBSpxi4p2

Why not challenge the status quo?

Are you selfish? Most wouldn’t like to answer yes to this question, but that’s only because it’s not desirable to have this quality. But here’s the definition:

Adjective.
(of a person, action, or motive) Lacking consideration for others; concerned chiefly with one’s own personal profit or pleasure.

I think if we really were to evaluate ourselves and determine whether we fall under this definition, we would find that we are at least somewhat selfish, but we would be okay with it. Relatively speaking, if most people are selfish to a common extent, then it wouldn’t be a bad thing; you would be normal (of the norm), at least not for simply being abnormal.

To be selfish is to be lacking consideration for others. Are we not doing this all of the time? Say we go to a Starbucks to buy a cup of coffee and a lunch item. A lot of the time (at least where I live), you’ll come across a homeless person. This homeless person would probably want a cup of coffee and a lunch item too. So, why not ask him if he does. If he says yes, then the selfless thing to do would be to get him one. In fact, you could even explain to the person behind the Starbucks register that this homeless person would like something but doesn’t have the money for it. The selfless thing to do for the barista would be to give the homeless person something(s) at no charge.

Yet, this rarely (if at all) happens because everyone is looking out for their own self interest (they’re technically selfish). The barista wouldn’t want to lose their job. You probably wouldn’t want to give your money away to every person in need (you couldn’t physically handle the demand). If we all take care of ourselves, then that requires us to be focused on the self, and focused on selfish things.

Looking at the the word “selfish” in this way, makes us realize that it isn’t such a bad word after all. Maybe next time when someone calls you selfish, you’re immediate thought or response could be “Aren’t we all?” But maybe they’re calling you more selfish or selfish to an extreme extent from the norm. In this case, ask whether you’re extension from the norm is bad. Challenge the status quo as to why it’s bad to be more selfish than usual. Maybe you’re being selfish for a good reason (i.e. there is valid rationale behind your decisions).

In no way am I suggesting that it is never bad to be overly selfish. The purpose of this post is to explain how it’s not always bad, nor is it always good. Things aren’t black and white, yet this is how we all tend to believe because of how we’re influenced. Think differently; we discover more this way. Thanks!

This is a follow up post to Natural Async Programming

Giving my thoughts more thought, I realized a concept that could change everything. Something that OOP did for the Macintosh era, could do for our era–the async revolution. I looked into some things such as Flapjax and Elm, and I discovered an idea that I’d like to define in this post, signals. Not signals in the Elm sense specifically, but signals in my own definition.

First, let’s talk about event emitters. Event emitters can emitter any number of events, and handlers can be attached to these events and be invoked when the events are emitted. This is very powerful, but in JS, this is all done with callbacks:

emitter.on('event', callback);
...

Now, I’d like to define a signal as a lower level form of event emitter, but rather than a collection of events, it is a single event, a single signal. Signals, however, are not done with callbacks. They’re handled automatically by the interpreter:

var signal = createSignal();
data = signal;

createSignal is just an example of a function that would create a new signal; signals are more ubiquitous that having a single interface for creating signals, i.e. an async function could return a signal.

The idea is that a signal is a value that changes over time. The value is used as you would any value, but the code is re-evaluated when the signal changes. This is analogous to an event being emitted.

In fact, data is a signal too; everything is a signal! Just like in OOP, everything is an object, in SOP (signal oriented programming) everything is a signal!

But if everything is a signal, then wouldn’t this get confusing when everything is changing? No, because some signals are static, and don’t change. If I create a function that just returns the number 23, that’s a static signal.

Back to the comparison to signals and event emitters. Event emitters in a signal-based language would just be a collection of signals:

emitter.event1;
emitter.event2;
...

These signals can change, reacting to these signals is as simple as just using them. But, sometimes you’ll want to be able to just do something when a signal changes. Well, you just use the signal, and that code will be evaluated on signal changes. So you could just do an if statement:

if (signal)
{
...
}

Though, sometimes in JS, you might have callbacks that don’t have values passed to them (like setTimeout/Interval). In these cases, if (signal) would evaluate to false because the value would be undefined in the signal. To solve this, there should be a statement just for handing signal changes:

when (signal)
{
...
}

It doesn’t have to be named when, it could be named on or change even.

Signal-oriented programming allows us to use all the power that functions give us but without the functions! Instead you just declare what happens in your program and when your program has signal changes, it responds. It’s a very enticing idea, isn’t it?

But, sometimes you don’t want to respond to a signal any longer. Take setInterval for example. If you had a similar function, interval that takes an integer for milliseconds as input and returns an undefined value for every signal change on that interval, you wouldn’t be able to clear this interval because there is no ID number to use to clear it. However, there is the signal itself, so all you need is a function that could kill the signal:

var intervalSignal = interval(1000);
when (intervalSignal)
{
  var num = Math.random();
  if (num*100 < 23)
    kill(intervalSignal);
}

The kill function will deallocate/garbage collect anything that is envolved with a signal. This function is probably unnecessary, because you could just use delete to delete the variable itself, but maybe kill() can do something more that delete doesn’t do (i.e. stop all variables that reference the signal from receiving changes, or maybe keeping the value of the signal without allowing it to change further).

In conclusion, I think the idea of Signal-Oriented Programming should be the next hot topic for programming language semantics. I personally think, signals, or something like it, could change the way we program, and the way we think about how computers work, forever.

JavaScript has really taken asynchronous programming mainstream, but some of the lessons we’ve learned along the way is that async is different. Rather than the usual linear program flow, you have these callbacks which can be nested or managed by a control flow lib. However, what if we dreamt something more natural for async programming, because async is awesome and it deserves it.

Promises is the idea that an async function returns an object which handles the outcome of an async action. I like this concept because you’re using the return statement where it should be used (output). Inversely, callbacks seem backwards: you use the input to handle the output of a function (how backwards). However, promises are still callbacks, just nicer.

I wondered then, what would it be like if we had async built into a language? How could this work? Could it even work? Let’s hypothesize.

Say the return statement was asynchronous in that the function would wait until it is used before it returns output:

function af(){
  return setTimeout(function(){
    return 'done';
  }, 1000)
}

Here, setTimeout returns what the callback returns, but it is async so it doesn’t return ‘done’ immediately. This is interesting, but the language would have to know which parts of the code depend on other async operations.

var foo = af();

if (foo === 'done')
{
   alert('second');
}

alert('first');

Sense the if-statement depends on foo, then the if statement is put on hold before, and the alert('first') statement is executed.

This will make parallel async and serial async almost invisible to the programmer:

// parallel invocation
var a = async();
var b = async();
doSomethingWith(a, b); // Final results

// Serial invocation
var a = async();
var b = doSomethingWith(a);
doSomethingWith(b); // Final results

Some more examples to get used to how this works:

var done = sleep(2000);
if (done) {
  alert('Done sleeping!');
}
alert('Sleeping');

var posts = db.query("select * from posts");
var comments = db.query("select * from comments");

// This next statement is using the pending variables
// so it will be queued until for later, automatically
res.render('template', {posts:posts, comments:comments});

// This will run before the above because it's not depending 
// on the async pending variables
Analytics.push(request);

Somehow, this could be possible with it being implemented at the interpreter level. Could it be done?

Here’s a compilation of the various things I suggest Apple fixes in Mac OS X. I’ll be adding to this list over time. (Warning, it gets very whiny)

1. In a fullscreen app, the menu bar shouldn’t appear until you move your cursor past the top most pixels. This is how the dock works for the bottom most pixels. It’s so annoying to have the menu bar get in your way when you mean to click on a tab in Terminal.

2. 1st Desktop should be closable/sortable.

3. NO. That’s directed toward waiting for the close button on desktops or needing to hold Option to show the close. Make this easier to do.

4. Trackpad gestures shouldn’t require that you lift your hands off the trackpad before you could initiate another gesture. For example, swipe up with three fingers to go into mission control, then swipe left and right to switch desktops, then pull back down to exit mission control.

5. You don’t need to move your cursor in order to click on a window in Mission Control. Right now, swipe up with three fingers. Now click on the window directly under your cursor. Nothing will happen, because OS X is being stupid. You need to move your mouse until a blue highlight appears around the window before you can click on it. So stupid.

6. Please squish bugs; I’m on a Mac right, not a PC? When I open mission control while an application is launching, the app will appear over mission control, not with it. And if I close an application while in mission control, well: http://cl.ly/image/0d2s2P3q1A1d

7. I want my RAM back.

How do I spend less time worrying about errors and more time focusing on what my functions actually do? I have these model files which are a collection of functions that accept an info object and a callback function. When something is missing, but required, in the info object, I error out calling the callback with new Error('missing info.something'). It’s not very DRY because I have to write the same if (!info.something) in my model functions whenever I choose to create a new function. But, I have to do it in order for my application to spit out meaningful error messages. This is the problem with async programming, at least for me.

Does anyone have any solutions to this? One where I wouldn’t have to worry about error handling; if something goes wrong, then my app will give a meaningful error (critical errors would crash the app, non-critical would just give a HTTP 500 status code).

I’ve spent hours trying to figure out how to install this. The problem isn’t with installing this particular tool, but it’s dependency, MySQLdb.

First, why is it called MySQLdb and not pySQL or something like that? It would make more sense as this has to do with some python bindings to MySQL, AFAIK. I don’t really know what the fuck this thing is for cause there’s very little information on it for noobs like myself. If this thing is a mysql server, then I don’t need it, I already have mysql installed.

I must say, I’m on a mac. And from what I’ve read, it’s notoriously difficult to install this on a mac from what the blog says (http://mysql-python.blogspot.com/). However, the “easy way” to install it is with MacPorts or Homebrew. I have homebrew, but brew install mysqldb doesn’t work, so WTF is the thing called? Thanks for mentioning that, Sir Blogger.

Could someone just help me out here. I’m cranking, stupid, and frustrated. I just wanted to get schemasync to work, and I didn’t want all these dependency headaches.

PS: If only schemasync was a Node.js lib, then it could take care of it’s own dependency installations. Node.js is beautifully simple, unlike all the other shit out there.

Short-circuiting is when an operator skips an operand because it would be pointless to evaluate. For example, with:

a || b

If a is true then there is no need to check if b is true, because a is already true therefore b’s value would have no effect on the evaluation of the entire expression.

Similarly:

a && b

If a is false, then there would be no point in evaluating what b is.

Taking this into consideration, which would take less steps to evaluate, !(a || b) or !a && !b?

I say that !(a || b) is faster. Why? Let’s first look at the expression !a && !b.

First, !a && !b would need to check what a is, then operate on it with ! before we get the first operand for &&. If the && operator short-circuits, then we effectively did only two things so far. However, if it doesn’t short-circuit (!a == true), then we have to do two more things (check what b is, then invert it with the ! operator), which will bring us to a total of four (4) steps. This is the expression’s worst case scenario.

Now, let’s look at !(a || b). We first check what a is; if it’s true, then we short circuit, and then ! is operated on the value true, which would only take two steps. This is the expressions, best scenario. However, if a is false, then we don’t short-circuit and we then go on to evaluate b; we then finally operate on the value of b with the ! operator. This is the expression’s worst case scenario, which is only three (3) steps!

So there you have it. !(a || b) has a better worst case scenario than !a && !b.

Any objections, comments, thoughts? Am I missing something, or does !(a || b) win the battle?

EDIT:

I created a JavaScript performance test to prove my arguments.

http://jsperf.com/not-a-or-b-vs-not-a-and-not-b

So far, I stand correct, and proud of it! :)

Most programmers are familiar with the age old “Spaces vs Tabs” debate. I’m pro tabs, and here’s why:

1. Tabs are one single character.
   • If you’re editor has regular expression search, \t will suffice to find all tabs. I don’t see how this is as simple if you use spaces.
   • One tab, one indentation. This makes more correlative sense.
   • Programmers could set tab width regardless of who else wrote the code. If programmer A wrote with 4 spaces tabs, then programmer B would be stuck with 4 spaces, unless they had an editor that could convert the 4 spaces to tabs, and then back to 2 spaces, or whatever display width programmer B would want. This is too much to think about IMO. If pro. A wrote using tabs, then pro. B wouldn’t have to do anything; his display width settings would have already been set, and it would display the tabs at a specific width wanted. In other words, tab characters can be presented in various ways (styled, so to speak) while spaces cannot; it’s like using a bunch of
     elements to add space to your HTML document’s presentation instead of just styling using CSS properties (margin, padding, etc).

Why wouldn’t I love tabs? Give me some arguments against tabs, so that way I may counter-argument them, if I find it possible/logical.

Let the discussion begin, please. :)

I created a routing script that takes a formated file as input which will tell the script to register routes for an Express application. Here’s how it works. In your main app.js file, do this:

var router = require('./routes.js');

router({
    routesFile: './express.routes', 
    routesDirectory: './routes/',
    app: app
});

Require the module/script, then call it’s exported function. Pass an object with three parameters to the function. The first parameter is the routesFile which is the formated file that looks something like this:

get /about
    page.js about
# Comment
post /some/path
    file.js method

Second parameter is a directory containing modules or scripts that export methods. Thirdly, the Express app object.

The routesFile’s syntax is pretty basic. Each line defines a route method (GET, POST, etc) and path (Express route path). Following that is a list of files and methods, all indented under the route. The method is looked up in the file and is registered as a handler for the route. Finally, single-line comments are defined by a single #.

I’ve been experimenting with this, and there are a few issues I have with this approach. One, there is no syntax definition for my favorite code editor (Sublime Text) for this file’s syntax; this makes it a bit difficult to read. Two, when developing, I use nodemon, and nodemon doesn’t restart my app when I make changes to this file.

The only benefits that I get using this file, is that I can see all my application’s routes in one place, and I have a simple syntax for defining a route, a syntax that wont limit me in any way (bcuz I haz the full Express route path syntaz).

Anyhoot, I’d like to get some comments on this. Should I turn this into an npm module, or would this be a disservice to the Node.js community?