I am a senior level Solutions Architect and ETL developer looking for work in the East Bay.Read More
It's official: I am going back to being a full-time breadwinner; so my focus has to be back on making money, and although I plan on continuing the music blog, I will have to be splitting my time now between blogging and other things that are more lucrative financially. I'd love to just write about music for a living, but right now it's only pulling in about 20% of the money I need every month to keep this family afloat. I will be rolling out other avenues for monetization, and plan to build out a web application to both use as a showcase for new tech clients and as web service for promotional purposes. I have long wanted to build a Twitter bot, and pull in all this awesome CHILLFILTR metric data to create some Business Intelligence. Fun.
I hope y'all had a great summer! If you know anyone that needs contract or full-time work for Ruby, SQL, or any kind of cloud BI, hit me up on LinkedIn. We are open to relocating anywhere around San Francisco.
So I have been party to a sort of bitcoin saga for months now. I had a miner running for a few months in the summer of 2014, and I ended up with about 1.3 bitcoins. At the time it felt like a bad deal, to make barely one coin over three months, so I just forgot about it. Enter this whole crazy crypto run-up at the end of this year and I started to wonder if that wallet was still doing all right. As it turns out, it's doing fine. It's getting money OUT of the wallet that is proving difficult.
You see, the blockchain is now around 160GB and growing. Armory then runs an index database along side, so I'm not sure if a 256GB SSD is enough to comfortably host a BTC wallet now. Plus you need at least 8GB of RAM and a decent processor; and of course a good internet connection. I had a little Dell Inspiron that I thought would do the trick, but man it was slow. 2 weeks to get the blockchain downloaded. Another few days to run the Armory indexes. And then, because Windows, the McAfee sales popup crashes the app and corrupts the index. Reinstall the OS. Repeat.
Anyway, it sort of became my white whale, until I realized that the hardware was just not good enough.
Now, I have this workhorse laptop that I had situated for running SQL and importing our massive database, it has tons of RAM and and large SSD and it is perfect for finally pulling up this wallet and getting those BTC out of there. I want all of my bitcoin to be ready to sell if the price gets too much higher.
So the blockchain downloaded over night; took barely 12 hours. Armory was difficult however. Here's what you do.
and that is all you need to get Armory running.
So anyway I am working my way through a Node.js proof of concept, and seriously I am having more fun than I remember having in a long time (Node + Express + EJS). Coding is fun, anyone will tell you that, that is how we all get hooked; but if you keep your head down long enough you may forget it is art at the end of the day. I can't tell you how excited I am to get started on something new. I've got a lot more interviews coming up and it all just feels really good right now.
It is really strange to be back on the market, so to speak, it has been almost a decade now since I've been looking for full-time work. But I feel really ready right now for whatever comes my way. And I have until next Friday to deliver on a pretty simple POC in Node.js, and I'm telling you, that app is going to fart rainbows by the time I'm done with it. :)
So after 20 years of doing this, I've learned a few things about the interviewing process. One of those things is the concept of a reverse interview.
For my example, I am going to use the interview I did for a company called Recurly (in San Francisco), they were based in the Mission near where we used to live and I was excited to finally get one of those 'warehouse' dev jobs, like I used to pine for in LA when I used to live east of Hollywood with my view of the downtown skyscrapers. So I get the interview, I talk to Scott, their lead dev, my prospective 'boss', and we hit it off like gangbusters. Seriously. I was super-excited to work for this guy.
And then he says, one last thing - we need our boss to sign off on you. He's going call you tomorrow. He's going to do an online 'code' interview. We'll call Scott's boss Steve. So Steve gets on the phone, hey how you doing, I am going to ask you how to code a binary tree, we need a left method and a right method and some sort of object. Pick a language. We were using a screen-sharing service, it might have been a shared google doc or something. I could type and he could see it. And I'm saying to myself, 'sweet! I just learned about data structures at Stanford - this is going to be easy'.
I had just finished a class about structures and algorithms at Stanford with Cynthia Lee, and although we used C++ for that I decided to write something with Ruby, because that's my go-to. And I decide to write an implementation using recursion, because had just finished that section with Cynthia and I was excited to show off.
ME: Ok, well the first thing we need is a base case.
STEVE: can you start with the left and right methods?
and it all went downhill from there. Basically, if you don't understand recursion, it can't be explained to you in a few minutes. It's like the concept of limits - you need some time to wrap your brain around it. And it became clear that Steve did not really understand recursion, or worse yet, thought he did but hadn't put it into practice.
I did not get that job, and for a while I was angry because I really liked talking to Scott, but then I realized, that Steve guy is running the ship. And he was a mess. Put simply: he decided to veto a candidate that his own manager had already approved, based solely on his own limited understanding of Ruby, and recursion, and his inability to see his own limits (pun intended).
So that's what the reverse interview is - if you are not paying attention, as an interviewEE, to all of the details available to you in terms of what kind of culture exists at the company, then you are missing a huge opportunity to vet the organization before you are tied down. I believe great organizations are easy to spot - as are uneasy ones. Most of the time all we have to do open our eyes, and pay attention.
EDIT: I was shooting for something like this implementation but I didn't think to rope in the enumerable module.
Breaking up is hard to do. I have been looking at this for over a month now and I'm seeing the writing on the wall.
We are still running 5.6, and we have run into a lot of issues getting the upgrade. Things like:
- Apparently 5.7 is so buggy that my PaaS provider suggests we don't do the upgrade.
- running 5.6 queries against 5.7 is a massive issue because the Group By syntax has changed, so just to get there every snippet of SQL that uses group by needs to be refactored.
- This is a tangent but I am very concerned about ownership of MySQL by Oracle. I am naturally cynical when it comes to private business, as I am a proponent of open-source software. I feel like businesses have become increasingly orthogonal to consumers, basically brushing them aside as they see fit, and over time it just devolves. I like to see a clear path stretching out into the sunset for the core products that I use, and for MySQL, I think those days are over.
- Everyone is jumping ship. I don't know anyone using MySQL anymore. Not that there is a significance there, necessarily, because I don't have that many developer friends, and I am not a blind follower, but it does perhaps suggest a simple truth - we have finally outgrown SQL and relational databases in general as the de facto answer for data storage. It is a more nuanced marketplace now.
So my angle will be to facilitate a move away from MySQL over the next months and years. Sounds like I have a lot of research to do.
I am even looking at R right now to replace or augment our BI so things could get pretty interesting. We will see.
Just out of college, I got a job maintaining an Access database for a legal firm in Wisconsin that was vetting different types of records for legal discovery. As a 'temp worker' registered with the local staffing firm, I spent about 10 months writing queries and importing spreadsheets and scanning documents for a team of paralegals. With that experience, I was able to launch a successful software development career on my arrival to Los Angeles in 1999 and through to present day where I own my own 1-man code 'shop'. My main expertise is and has always been dealing with data, and managing the process from OLTP to OLAP and on to business intelligence, which is where a lot of progress is being made right now. Just in the last few years I have seen a preponderance of many new outfits in this space, and that is mostly a good thing but can be a bit wearying to vet so many similar products. I will be writing a few things around this topic so I am labeling this part I.
I am going to wait on doing a top list of anything, or start comparing products. But what I do want to do today is talk about Shiny. Here is a simple proof of concept that I created, where you can select a number of random 'seeds' and the application will automatically create a histogram of the normal distribution of those random numbers.
Now this might not look like much, but for me it is an absolute revolution. First of all, the speed - R is built for what you call 'medium data' analysis - which fits right between the 'small data' and the current buzz-word 'big data' (at least according to Hadley Wickham, chief scientist at RStudio). And even in the OLAP / medium data space, you run into speed issues. Constantly. Different platforms handle that differently, which I will talk about some other time, but right now let me be very clear - R-backed ShinyApp is way ahead as a service, because R is way ahead as a data crunching platform. The advantages vs. SQL are already very clear to me and the truth is that most businesses, large and small, will probably never get to a NEED for big data. And I can't possibly imagine a scenario where it would NOT benefit you to spend a long time playing with your data and creating models in R, even if you plan on going directly to Hadoop or BigTable or Redshift. It's just the right place to start.
And finally, along with the speed of it, the reliability of the shiny app server is great. I have seen nothing to suggest it won't scale, and I think it will soon become a real competitor to the current leader in the white-labelled embeddable BI space, which IMHO is Mode Analytics.
Next up for this series will be to flesh out a bigger shiny app with some more meaningful data, which means I will have to navigate the date selection functionality as input, and use that to rewrite the output. I'm thinking of a day of the year slider, with maybe some heat maps so you can drag across a timeline and watch the daily micro-swings in denomination distribution which might be an aha for somebody if I hook it up to some sales data.