I don’t know about you, but I think Travis CI is the best thing that happened to open-source development since Github.
I noticed that my builds seemed to be getting slower lately. Looking at the build history in the regular Travis CI interface wasn’t very conclusive, because you can only see 10 or 20 builds at a time:
Even after pressing the “Show more” button repeadetly, I still wasn’t sure that it wasn’t just a random fluctuation. What I needed was to see all the builds at the same time.
After a few hours of reading the Travis API docs and fiddling around with D3, this is what I came up with:
It incrementally loads the most recent ~500 builds and plots them individually and again grouped by day. Clicking on one of the thin bars sends you to that build’s page on travis-ci.org where you can see all the available information about it.
Looking at the build durations bar chart on the left, you can see that builds have indeed gotten slower, from 15-20 minutes per build, to about 20-25 minutes.
Implementing single-page web applications that work on all browsers remains a challenge. For the basic task of uploading files, you still need some sort of polyfill or library that adds support for older browsers (read IE 8 and 9, which are still in wide use).
In this tutorial I’m going to describe how to integrate one such library, called mOxie, with one client-side MVC framework, called Ember.js.
0. Getting the mOxie library
I’m going to assume you already have an Ember app going, so the first step is acquiring the mOxie files. You can either use the pre-built files or compile your own. For example, we won’t need XHR2 support in this tutorial, so we can leave it out.
1. Defining the template
The next thing we have to do is write the Handlebars template that will contain all the UI elements we need:
The UI has several components:
error and progress notifications
the list of selected files
the button for selecting more files
the button for initiating the upload
2. Initializing the file picker
In the template above we placed the button inside a view. We can use that view to convert the <button> into a file picker:
Here we create a mOxie.FileInput instance once the template containing the button is rendered.
3. Adding/removing files
The view we defined in the previous step will send events up to the controller, which has to respond to them:
The neat thing about Ember.js is that it will automatically re-render the template whenever the attachments property is modified.
4. Uploading the files
Finally, when the user wants to submit the form, we have to actually send the files to the server:
We start uploading all the files concurrently. When one is done, we increment a counter. When all of them are done, we clear the queue. Did I mention promises are great?
And here are the helper functions used in the controller above:
I wrapped both the mOxie.FileReader process and the AJAX request in RSVP promises so that chaining and utility methods such as .catch() always work as expected.
Demo
I’ve set up a quick demo so that you can see it in action.
This is just a starting point, of course. You can add all sorts of usability enhancements, such as progress bars, image previews etc. Happy hacking!
“Where are the people?” the little prince asked, politely.
The flower had once seen a caravan passing.
“People?” she echoed. “I think there are six or seven of them in existence. I saw them, several years ago. But one never knows where to find them. The wind blows them away. They have no roots, and that makes their life very difficult.”
The PHP world is not known for good unit test coverage. It’s mostly a cultural issue, but there is a technical aspect to it as well.
PHPUnit allows you to create mock objects, but that assumes your codebase uses the Depedency Injection pattern. If not, it’s very hard to add unit tests without doing major refactorings, because the language doesn’t support monkey patching (i.e. redefining functions and methods at runtime).
You could install the runkit extension, which allows you to replace everything, including constants. However, that means that anyone who wants to run the tests needs to re-compile their PHP.
Patchwork is a PHP library that makes it possible to redefine user-defined functions and methods at runtime, replicating the functionality of runkit_function_redefine in pure PHP 5.3 code.
I started using it to create mocks and it’s great, but I had this nagging thought: how the hell does it work?
I set out to figure out what black magic the author uses, only to find that he already wrote a very easy to understand description of the implementation, like any responsible developer would. Neat!
Gems like these are few and far between in the PHP ecosystem, but they do exist.
Science (from Latin scientia, meaning “knowledge”) is a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe.
Most people, whether religious or not, agree that the scientific method, as described above, is a Good Thing.
Unfortunately, since the nineteenth century, the scientific method has been tightly coupled with a belief system called materialism:
In philosophy, the theory of materialism holds that the only thing that exists is matter or energy; that all things are composed of material and all phenomena (including consciousness) are the result of material interactions.
The main thesis of Rupert Sheldrake’s book, Science Set Free, is that science is being held back by this dogmatic belief in materialism. Below is a TED talk in which he summarizes the book, much better than I could:
In an ironic twist, the above video was banned from the official TED channel, proving that some ideas are taboo and will be deemed “unscientific” by the establishment, evidence be damned.
It’s a well known fact that, in English, the way a word is spelled can have little or no relationship to the way it’s pronounced. As a native speaker of Romanian, which is a phonetic language, I find the pronunciation of single vowels particularly confusing.
To illustrate, here’s a completely non-scientific correspondence between what an English speaker thinks he’s saying and what my brain translates it to:
Letter
What I hear
A
EI
E
II
I
AI
O
ĂU
U
IU
Y
UAI
Because of this, my chances of ever winning a spelling bee contest are severely handicapped.
A Mathematician’s Lament is this poignant essay 1 from a few years ago that I just discovered. I highly recommend you go read it now, because I’m going to give spoilers.
In the introduction, the author makes the case that mathematics is a misunderstood art form, where the medium is imaginary objects (such as numbers and the patterns they form), instead of paint or marble. It’s not science, since it doesn’t try to understand reality, bur rather made-up things, like triangles and curves. It’s not engineering, since the focus is not on making something useful. Any practical benefit that arises from doing math is just an added bonus.
With this mindset, the author then goes on to decry, in a rather entertaining way, the horrendous state of math education. 2 In short, the system is focused on all the wrong things (notations, definitions, formalisms) and none of the right things (natural curiosity, intuition, elegance, context).
So, while sir Ken Robinson was completely right when he said that schools kill creativity, in the case of math, the education system did such a good job, for such a long time, that the common wisdom is that there isn’t any creativity in mathematics to begin with. Or that you have to be a genius to enjoy doing math.
Before reading this essay, I had this vague guilt for completely losing interest in math in high school (and, consequently, barely making it through the math courses in college). I think I can relax about it now. I would still like to learn, but not because “I might need it someday” and not even because it might make me a better programmer. Just because it might be fun.
It seems it was later expanded into a short book. ↩
The author is from the USA, but I had an essentially identical experience as a student in Romania, so I’m going to assume that it’s pretty much the same everywhere. ↩
I was recently assigned to work on a node.js project — a first, for me. I discovered that it comes with a neat CLI debugger built in, which is very handy when diving into an unknown codebase. However, when inspecting a variable, it doesn’t show me its type; only its value.
First, let’s see how you would get the type of an object in other dynamic languages.
In Ruby, every object responds to a class message, which returns an object of type Class, which responds to a name message, which returns a string:
obj.class.name
In Python, every object has a __class__ property, which contains a type instance, which has a __name__ property, which contains a string:
obj.__class__.__name__
In PHP, there’s a special get_class() function which returns the class name of an object as a string:
get_class($obj);
In JavaScript, every object has a constructor property, which contains a Function object, which has a name property, which contains a string:
obj.constructor.name
Update: Got a link on twitter to a much more in-depth discussion on StackOverflow, with various caveats and workarounds. But for getting a general idea of what kind of object a variable is, I think the above method is good enough.
When we are debating an issue, loyalty means giving me your honest opinion, whether you think I’ll like it or not. Disagreement, at this stage, stimulates me. But once a decision has been made, the debate ends. From that point on, loyalty means executing the decision as if it were your own.
