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 »
This has been plaguing me for years and I finally figured it out. Thanks
to eleperte who created
ssh-xdg-open, I was finally
able to see what to do. Ssh-xdg-open didn’t work for me, but there was
enough information available for me to figure out the missing pieces.
Forget about gconftool and you don’t need ssh-xdg-open. If all you
want is working ssh://protocol links, then just use xdg-mime to set the
default application for handling ssh protocol links and create an
application handler with the same name as that application.
xdg-mime default ssh.desktop x-scheme-handler/ssh
cat << EOF > ~/.local/share/applications/ssh.desktop
[Desktop Entry]
Version=1.0
Name=SSH Launcher
Exec=bash -c '(URL="%U" HOST="\${URL:6}"; ssh \$HOST); bash'
Terminal=true
Type=Application
Icon=utilities-terminal
EOF
All this does is launch bash, parse the host from the URL and executes
ssh. When ssh exits, it executes bash again so the window stays open. I
wrote it this way because you can’t count on everything to work all the
time and if you don’t keep the window open, the error messages will
vanish into the ether and your sanity with them.
Continue reading »
Like the rest of the world, RightScale has been moving more and more of
its application from the server to the client. That means we’ve suddenly
found managing larger and larger piles of JavaScript. All that
JavaScript needs to be delivered to clients as quickly as possible in
order to minimize the time customers spend waiting for web pages to
load.
So we created a nice little build tool leveraging
Grunt which among other things takes all that
JavaScript and compiles it into one big blob for each application. In
order to make that big blob as small as possible, we use
UglifyJS.
Unfortunately, some of our apps are so big that running the uglify Grunt
task can take a long time. Ideally, this task would be fast enough to
where it could be run at or just before deploying. Fast enough is a
pretty subjective term, but we deploy code all the time to production
and various kinds of staging systems, so fast enough becomes however
long you want to wait for code deploys in addition to the time it
already takes. In my case, three extra minutes is not fast enough.
So I theorized about the virtue of using UglifyJS at all and my
reasoning went something like this: Any sane person who’s delivering a
lot of JavaScript to clients on the web is going to be using some kind
of HTTP compression
algorithm like gzip or deflate. And hardcore file size optimizations
prior to compression seem like exactly the kind of things that would
make regular file compression less efficient. So wouldn’t we be better
off with something fast and simple like Douglas Crockford’s good old
JSMin? We could just
rely more on the file compression than mifification or uglification to
reduce file size.
Continue reading »