Hacking in everyday life (fun with the Sprint API)
Let me explain the situation I found myself in last week:
If you didn’t already know, Sprint is offering a free year of unlimited service through the end of July if you port your non-Sprint number to them. It’s a great deal, but if you are not a Verizon customer, they really make you work for it. If you’re with a smaller carrier, the free years page will probably say you are ineligible, even if you have an eligible type of device. That’s because Sprint maintains its own database of phones with some indicator on each record saying whether the phone is on the Sprint network or not (you heard me right: a database of phones that are not on their network). So, if your carrier (like mine) has not told Sprint that your phone is not on the Sprint network, the Sprint system assumes you are ineligible for the offer.
The solution is to create a support case with Sprint to get your device info (WiFi MAC address, IMEI number, phone number, make/model, and current carrier) added to that database. From the experience of family members who tried this, I know it would take up to three days for the information to get processed into the database and reflected on the free year page, and potentially longer for me to get the email from Sprint saying everything is hunky-dory. But time was of the essence, so I would have to check the free year page every few hours to try and find out when the offer was available for each of the devices I wanted to port. What a hassle!
This is where being a developer comes in handy.
Taming untracked files in a large git repository
Have you ever tried to add a NuGet package to a Visual Studio project but accidentally added it to the whole solution? And now you have 100 untracked .config files showing up in your changed files list? Or have you ever stopped git in the middle of a big rebase and end up with a lot of new files on your machine and you need to rewind and get to a pristine state?
Well, that’s why we have
git clean -fd. But if you work in a very large codebase like I do at work, that command takes forever to run. I’m talking “go to your one-hour meeting and hope it finishes by the time you get back” forever.
Luckily, if the number of files that show as untracked is manageable, there’s a faster way to get rid of those pesky untracked files than running
There are two types of engineers. Be both
A while back I listened to this talk. It’s by Michael Lopp– an engineering head who worked at companies like Netscape, Apple, Pinterest, and now works as Engineering VP for Slack. Pretty bright guy. At any rate, in his talk, he broke engineers into two basic archetypes: the stables and the volatiles.
Writing a Personal Automation API: Part 4 - Your First Integration
In my previous post, I outlined how to add authentication to the personal automation API we’ve been building using Google Apps Script. Now I’ll talk about how to start harnessing the power of the Maker channel on IFTTT to connect our API to anything and everything we want to, starting with Nest as an example.
Writing a Personal Automation API: Part 3 - Authentication
In my previous post, I outlined how to start building a framework for a personal automation API hosted on Google Apps Script. With the code from the last tutorial, we’re almost ready to start adding in services and integrations to the API. but before we get to that point, there’s still a little bit of work left to do on the framework: authentication (and all the helpers we’ll need to accomplish that).
Writing a Personal Automation API: Part 2 - The framework
In my previous post, I outlined how to begin writing a personal automation API with Google Apps Script. Really, it was just how to write a quick Hello World app that POSTs back with a message. In this post, I will go through the steps of adding a basic framework for running our API application.