As you probably do not recall, this blog was not always running on Wordpress. In it’s first incarnation, it was actually running Drupal . And as of yesterday, we can add Wordpress to the list of former lithostech.com platforms. Jekyll Homepage, Feb 2015 This site is now running on Jekyll, and since it seems to be relatively unkown compared to wordpress, I thought I’d take the opportunity to explore this change and explain the move. What follows could be looked at as a comparison of Wordpress to Jekyll as a blogging platform.

Theming

Wordpress has served me well. There are plenty of free, prebuilt themes ready to rock. Sadly, if you’re searching for Wordpress themes and you only consider themes that are mobile-friendly, SEO-friendly, easy to work on and not full of bloat, you’ve already elimated the vast majority of both free and paid themes that are available. If you want something visually appealing, you’re really down to a small handful of available themes which means your only real option is to use one of those and extend it, or write your own.

This is a bit daunting, but totally possible, especially starting from an example. Just read theme development docs and have a great time. You can <?php var_dump($foo); die(); ?> your way to a complete theme if you have the time, but unless you’re very familiar with this theming API, it’s going to take a while. It’s possible to do just about anything you can imagine, but I found theme authorship to be slow and painful and more than a little annoying.

Jekyll uses liquid for templating which is quite powerful and much more compact than plain PHP. After all, Jekyll is a much simpler tool than Wordpress, and for me that simplicity is a core strength. Have a look at this page’s layout to get an idea of how simple it is to write Jekyll themes.

Continue reading »

JavaScript dependency injection is all the rage these days. But after looking through all the options, I just haven’t found the perfect framework. That’s why I’m introducing my own framework to provide the best possible interface, helping you to inject exactly the dependency you need.

First, I want to introduce the problem we’re trying to solve. Let’s say you have a JavaScript function that has a dependency, but the client knows too much about the dependency. This is what smarty-pants engineers call “tight coupling”:

function Dependency1(say){
  alert(say);
}

function Client(){
  new Dependency1('hi'); // bad! tightly coupled interface
}

new Client();

Continue reading »

Suddenly this topic seems to be all around me. Although, I’m not sure if it was always here, or if I just wasn’t paying attention. But it’s here in a big way. The meritocracy discussion seems to be mainly about women in tech, but to a lesser extent, minorities.

At first it was an old colleague of mine on twitter. And frankly, I was annoyed to see his many-times-a-day posts about feminism and how the whole world is conspiring to keep his daughter from enjoying science and math. It went on like this for years and I eventually stopped following him because he never talked about anything else and I was tired of his rant.

What I didn’t understand at the time was this was all part of a much larger discussion. Although I did notice the growing trend about a year ago and started to take notice. Looking back at stories from the past few years shows just how much attention this is getting from major internet media outlets: Tech Crunch, The Guardian, Quartz, The Atlantic, Wired, NPR, The Boston Globe. You can even watch the rise of the term ‘meritocracy’ on Google trends as it begins in early 2009, likely in association with its so-called myth.

Recently, I also ran across an indiegogo project called CODE: Debugging the Gender Gap which promises to explore the lack of diversity in the tech world. At this point, it’s fully funded and I’m excited to see it when it’s ready.

Today, the discussion seems to be finding new ground after Microsoft CEO Satya Nadella’s remarks caused a minor internet storm, where he made some regretful remarks about how women should behave regarding salaries and ended up having to take it all back. And that’s great, the man ate his silly words and hopefully we all learned something.

Continue reading »

Through our work on the OptionsHouse API client, we’ve somehow become known as trading algorithm experts. At least once a week, Branded Crate gets a phone call or email from someone who wants to automate trading activity. To even have a thought like this requires some level of sophistication. Even so, many potential clients aren’t aware of what it takes to create and manage a system like this. That’s our area of expertise, so if you’re considering trading automation, read on to learn more about how we do it.

The very heart of any trading algorithm is the actual algorithm, written using instructions a machine can understand (code). This is mainly what clients think about when they talk to us. The idea generally seems simple at first, but complexities emerge as you begin to consider automation. Without even thinking, clients “just know” to do things a certain way as they execute their trading strategies manually. Computers, on the other hand, don’t know anything.

Let’s say a client wants to buy N shares of some stock when the current price of that stock is lower than it was at the same time on the previous trading day and sell when the current stock price is higher than the same time on the previous trading day. This is probably a terrible strategy, but ignore that because it can still serve as an example of how and where complexities emerge.

Continue reading »

As a developer, I’ve long struggled with the problem of how to deploy the applications I create. In an ideal world, I could spend all of my energy doing what I do best (building applications), and none of my energy dealing with operations concerns. That sounds like a good reason to have an operations team. But an operations team has the same problem because ideally, the operations team could spend all their time handling operations concerns, and none of their time worrying about how applications were created.

Deploying an application is largely an exercise in defining (or discovering) the relationship between an application and its environment. This can be a tricky and error-prone job because there is so much variety in applications, environments and the people who create them. If everyone involved could agree on an interface contract, we’d all save a lot of time and energy.

This is what PaaS has tried to do. Solutions like EngineYard, Heroku, Google App Engine, and OpenShift have sprung up to varying degrees of success. Of these, Heroku has had the largest impact on the way we think about software service deployment and what PaaS can do. You can find an entire ecosystem of software packages on GitHub designed to make your applications adhere to the tenets of The Twelve-Factor App. And that’s a good thing because we’re starting to see what life could be like in a world where apps fit neatly into PaaS-shaped boxes.

Continue reading »