Greggles, Gregorybeans, Frijoles, Beans
My schedule is pretty flexible: 7 to 5:30 most days.
Monday busy from 10:30 to 11:30.
Tuesday busy from 7 to 9 and 4 to 5:30.
Wednesday busy from 4:00 to 5:30.
Thursday busy from 8 to 9:00, 10:30 to 11:30 and 4:00 to 5:30.
Friday generally free.
You could also call this "Free Nexus5 if you switch from AT&T or Verizon." Here's a comparison of the plans and how I arrived at the idea of "Free" Nexus 5.
|Phone purchase price||Subsidized $200 every 2 years||No subsidy|
|Monthly cost for 2 lines||$190||$90|
|Data||Unlimited originally, switched to 2GB for the same rate||Unlimited (2.5GB cap, after that 3G service)|
This chart shows how much money both of these plans cost. I used a MotoX as the subsidized phone since it is similar in specs to the Nexus 5.
For our 2-phone-household, we had been spending $4,658 in a 2 year cycle compared to our annual of $2858. Both of those numbers feel pretty high, but at least with StraightTalk we're saving $1,800 in a 2 year cycle. Source data for that chart is in this spreadsheet
Let me say that again: $1,800 savings in a 2 year cycle! We could actually buy a new Nexus phone (or similar) every year and still save money compared to Verizon.
Enter the Nexus 5 and StraightTalk
Once you've gone beyond a trivial number of Jenkins jobs you can get into a situation of not knowing which job does which thing. You might say "I know some job is running a query on a table, but which one?" in that case it can be helpful to search your Jenkins jobs.
Managing Jobs by script size
We have two strategies for managing Jenkins jobs: put short scripts into the job itself, but move longer jobs into code somewhere else.
Most jobs use the "execute shell command" Build Step. I also use and recommend the JobConfigHistory plugin to see how a job has changed over time (or who fixed/broke things). When the number of lines in your "shell script" section of the job gets over a maybe 3 or 4 I think it's time to move things to "real code" that is managed by a revision control system with more power than the JobConfigHistory plugin (i.e. git). So, we tend to put things into one of four places: R scripts, Pentaho jobs, Drush commands or bash scripts. All of the R scripts, drush commands and bash scripts are managed with git. The working checkouts of those directories are updated periodically (...by Jenkins jobs :)). So, if I want to grep that external code to see where a particular table is being modified it is very easy to do that. But...what about the one or two line shell scripts that are inside Jenkins jobs?
Searching Jenkins Job config files
First, you have to know about the Jenkins directory structure. The job configurations are stored in files called config.xml located in the Jenkins home directory (often /var/lib/jenkins/). So, if you have a job named production_deploy then the config file for it is located at /var/lib/jenkins/job/production_deploy/config.xml
Compare all these different ways you have to install and update software on Mac:
- The app store - obviously this is what Apple wants, but they have rules about what can and can't go there and the rules don't match the rules their customers want (e.g. easy in-app purchases) but instead what Apple wants (more money).
- Download software from a website and install it. This works OK, except that the vendor has to get a key that is verified by Apple (which has its own legal paperwork for the developer to pretend they read). If they don't get a key then the user has to follow this Apple knowledge base article that includes advice to control click, use the context menu, answer a dialog and then it will work. That was simple, right?
- If you downloaded software from a website, it might update itself (For me, Sublime, Source Tree, and Adium all do this). OR, you might have to periodically go back to that website and see if a new version is available and then download and install it (Looking at you, Dropbox).
- Homebrew, Macports, etc. What is this, Gentoo? Since when is compiling source all the time a user friendly idea.
- My favorite scenario? When I need to get software X which comes via one channel. But I have to also get something it requires which comes via a different channel. Rough.
The App Store is clearly the most user friendly option, but as a user or developer I have no control to adjust its behavior. I can't say "Get stuff from the official Apple channel but also get new software and updates from the Dropbox website.
Glossing over the issues with unsigned packages, having a variety of different methods to install software that are inconsistent with each other means I have to spend more time remembering and researching the software.
For the past 1 year, 1 month, 1 week and 1 day I've been working at CARD.com. I love it. I've had a lot of great jobs in my career so far, but this is one that is truly extraordinary.
I'm currently pretty enthusiastic about a set of quotes from Jeff Bezos compiled at fool.com, so I'm sprinkling some of those through this post.
What is CARD.com doing?
Our CEO put it like this in a recent interview he gave:
CARD.com is the world’s first likeable financial company. We make payments fun, fair and fashionable. CARD.com offers Visa cards and MasterCard cards featuring card art and amazing perks from the best brands in the world, like Star Trek, Elvis or The Walking Dead.
And...that's a good description of what we do. But, what do I think we're doing that is exceptional?
- We're using a ton of open source software and contributing back where we can. That just warms my heart :)
- We're doing everything with an eye towards scalability. We have a lot of card designs and many more are coming. Some of our designs are big and some are small. We still want to delight the people with a "small" brand because to them that brand is their life.
- Bezos said "Your margin is my opportunity." and we're following that. We aren't aiming to be the cheapest provider, but we are undercutting a lot of other providers with what we believe is a much better product. That will help us scale and as we scale big we win. It feels great to provide a product that is competitive with other options available to our typical cardholder.
- Since we're scaling big, we sweat the small stuff. We review contracts to see how we can squeeze pennies or fractions of pennies out of different transactions.
We recently were reviewing proposals from two vendors. One vendor claimed 100% uptime. Another vendor claimed 99.95% uptime. Our SLA to customers is below both of those numbers, but 100% feels better than 99.95% right? So we should go with 100% right?
My experience is that the uptime number in an SLA is purely for marketing purposes. Pure. Marketing. Purposes. If you read 100% and think the service will be online for 100% of the time? Shame on you.
The really important thing is the detail behind the SLA. Here are a few tricks I've seen that make a 99.999% SLA roughly worth nothing.
- What are the exclusions? Most service providers are hosted somewhere (Amazon? Physical space?) that has it's own uptime guarantee. If that provider goes down is your SLA still in effect? Many SLAs exclude acts of nature like a hurricane that can take down a single provider.
- What do you get when the number is broken? Some contracts give you a credit. Some give you cash. Some give you a credit that is worth your monthly cost multiplied by the percent of time they were offline. Is that worth much to you?
- Do you get more if the outage is persistent? If a service dies for an hour that's a problem. If it dies for a day that is horrible. I want to be compensated more if the outage is prolonged.
- Whose monitoring counts? What kind of monitoring? I've had times where my monitoring (Pingdom) showed a site was offline for hours, but internal monitoring showed it was fine. I got no credits.
- What counts as "down" - if the service is online but taking 10 times longer than normal to process requests, is that OK? What if the service is online but network connectivity is degraded?
- How are periods of downtime calculated? An SLA I read only counted a full hour of continuous downtime as real downtime. Many outages are 10 minutes here, 20 minutes there. I want to be compensated for those as well.