As I keep repeating, CAPEX is both a prerequisite to play in the big boy cloud and confirmation of customer success. Both IBM and Oracle are tens of billions of dollars in cloud infrastructure CAPEX behind Amazon, Google, and Microsoft. Oracle’s spending has at least ticked up, but their spending is not enough to keep pace, much less to have any hope of catching up to the infrastructure of the big three.
The whole post is worth reading if you are interested in public cloud providers in any way.
I, along with many others, received this email last week:
Participating and watching the Colorado tech community evolve has been an amazing experience. Over the past 12 years we have had so many people engage and support our efforts. This includes the attendee’s, presenters, organizers, and sponsors. Give yourselves a big hand, IMO you are the reason Colorado has such a vibrant startup ecosystem.
I’m saddened, but it is time for me step away and stop organizing/hosting the Boulder chapter of New Tech Colorado. I’ve attempted to find a replacement over the past year, but no one has stepped up. I think thats ok, we have many other pitch events happening throughout the front range, including other New Tech events.
The Boulder New Tech, starting with the June event will no longer accept reservations and I’m going to shut down BDNT.org.
Thank you for giving me your attention and for sharing your experiences over the past 12 years. See you around town.
It was from Robert Reich, the moving force behind the New Tech Meetups here in Colorado. After over a decade, there will be no more Boulder meetups (though it looks like other cities are going strong, at least from the meetup page). I totally understand where Robert is coming from. I’ve been to many of these meetups, but over the last couple of years attendance was definitely down. However, every time I attended I met interesting people and saw a different slice of the Boulder ecosystem. I will say that it seemed like BDNT was a welcoming initial introduction to that ecosystem, but once a newcomer understood the landscape, I think they were better served by a more focused meetup. I know Robert experimented with a number of different formats and concepts–I hope he writes them all down for future meetup organizers.
I also had the opportunity to speak a few times at BDNT. Once I presented on GWT, which was my first experience talking to a group of over one hundred people (note to self, don’t present a technology at a pitch night 🙂 ). I also spoke in Denver with Brian Timoney–that was fun because of the 3d google earth submarine navigation demo and because Josh Fraser met with us and gave us some tips. And in 2016 I presented the startup of which I was a co-founder. Each time the community was very supportive and helpful.
I want to thank a few folks:
Institutions don’t have to live forever (especially those that survive on the efforts of volunteers). It’s OK for them to end. I will miss the BDNT event, but I know the community of support for entrepreneurship in Boulder and the front range is larger than ever.
Fare thee well, Boulder New Tech.
I saw a discussion about storing data in one of my slack channels and saw a line too good to leave in the slack.
Here’s a data storage decision tree for 95% of applications. Do you have data to durably store?
1. Use an open source relational database
(The original poster specified PostgreSQL, but MySQL/MariaDB are viable alternatives in my mind. Each has different strengths.)
The modern, open source RDBMS is flexible and scaleable (even web scale [warning, video has cursing]). It’s free from licensing fees (though you can pay for support). There are turnkey solutions for managing it in the cloud. There are plenty of developers who know how to use it (even more developers know how to use SQL) and many DBAs and sysadmins who know how to tune it. . You can scale it out by using read replicas and scale up by buying better hardware (or VMs). Every language has a library that talks to RDBMS. The database will maintain data integrity. Many tools that non technical users favor can connect to them (even Excel, if you install the right ODBC driver).
There are plenty of other solutions out there (filesystem, no SQL variants, xml databases, data lakes). They exist for a reason. For certain problems and at certain scale they are better solutions than the Swiss army knife of a RDBMS. But the default decision should always be an RDBMS, and the onus should be on the other solution to justify its present. For 95% of problems, the your default should be MySQL/MariaDB or Postgres.
A server on which I am working runs this command: /usr/bin/gem install --no-rdoc --no-ri aws-sdk to get the aws-sdk. I was seeing this error message:
Error: Execution of '/usr/bin/gem install --no-rdoc --no-ri aws-sdk' returned 1: ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError)
bad response Too Many Requests 429 (https://api.rubygems.org/api/v1/dependencies?gems=aws-sdk-elasticloadbalancingv2)
Every time I ran it I’d see a different gem that triggered the 429 response. There wasn’t much out there when searching, other than a note that I should update to a new version of bundler (which I wasn’t using).
Finally, I figured out how to get past this. What I did was manually run /usr/bin/gem install -f --no-rdoc --no-ri aws-sdk multiple times, and each time the command would get a little further. Finally all the dependencies had been downloaded. Then I was able to run it without the -f switch after that.
I saw a discussion on a slack about obstacles to high availability systems and wanted to record the edited version for posterity (mostly for future me, as I blog for myself). Note that in any mention of high availability systems would be remiss if I didn’t mention the Google SRE book, which is slow reading but free and full of great information.
First, what is high availability? I like this definition from Digital Ocean:
In computing, the term availability is used to describe the period of time when a service is available, as well as the time required by a system to respond to a request made by a user. High availability is a quality of a system or component that assures a high level of operational performance for a given period of time.
Design considerations of a system that will hinder high availability fall into two categories.
The first category is actions that you don’t take, but could take:
The second is in actions you can’t take because of external requirements on the system:
Again, this was a discussion from a slack of AWS instructors, but the commentary is mine, as are any mistakes. Thanks to Chad, Richard, Jon, Ryan and everyone else!
I’m doing a short presentation with a few other people at Boulder Startup Week on hosting. Tomorrow, Thur, at 10am MT.
Would love to see you there. Feel free to heckle.
If you can’t make it, here is the salient point of my presentation: startups are hard, so you should host your code and infrastructure at the highest level of abstraction that you can, so that your developers can focus on delivering business value through new features rather than doing ops. In practice, prefer hosting options in this order:
Of course, all advice is context dependent; my advice is aimed at small startups and the more flexibility your developers need around aspects of technology the lower on the list you’ll have to go.
Anyway, looking forward to a good discussion.
I loved this post not because I love reading assembler but because it just illustrates so perfectly how often, when writing software, we can easily stand on the shoulders of giants.
My point is not that we should take what we’ve learnt from the LLVM-generated code and write a new version of our hand-rolled assembly. The point is that optimising compilers are really good. There are very smart people working on them and computers are really good at this kind of optimisation problem (in the mathematic sense) in a way that humans find quite difficult. It’s the job of language designers to give us the tools we need to inform the optimiser as best we can as to what our true intent is, and larger integer sizes are another step towards that.
Boulder Startup Week is this week. If you haven’t been, it’s a great opportunity for a number of reasons. You can get a flavor of the Boulder tech community (though it’s worth remembering that there are numerous firms that don’t play in the startup world that are in Boulder). You can learn a lot about startups from folks who are actively building one, or have built one in the past. You can learn about new technologies and trends that are up and coming, including data science, blockchain and cannibis. And you can meet a lot of great folks.
I’m a bit burned out on startups at the moment, but am still planning to attend a few sessions, mostly on the development track. I’m especially excited for the Boulder Ruby Meetup on Wednesday, where experts will speak about interviewing. I’m also speaking at a session on hosting.
My tips for Boulder Startup Week:
If your interest has been piqued, please check out the schedule. Hope to see you out there.
One of the nice things about blogging for so long is that you get to see the wheat separated from the chaff. If I’m still thinking the same thoughts five years or a decade later, that means that I’ve stumbled on one of my truths. (That or I’m just echoing my thoughts because I haven’t learned anything new. I believe it is the former, especially when it comes to development, something I spend a lot of time thinking about.)
Here’s my 2012 post about the difference between a programmer and a developer. A programmer can be a great coder, but stops when the code ends. A developer uses code to build a business solution. (Pssst, a programmer is much more likely to be replaced by an offshore “resource”.)
One of my favorite analogies for developers is the bike messenger. She may not be as fast as a car or as flexible as a pedestrian, but she can weave back and forth between the street and the sidewalk in a way that neither of those two other modes of transportation can. And in the end she’s all about the destination, just like great developers are.
Somewhere, sometime, someone will do something wrong. It happens more often than you think. (That person might even be me.)
When they do, I have an innate desire to correct them, to show them the benefit of my mistakes and to enlighten them. This is, in itself, wrong.
What should I do instead? A couple of things.
In short, rather than just explaining to someone why they are wrong, I need to stop and think about the entire context of the situation, including what I’ve missed, what the consequences of the action are, and my role.
Follow me on Twitter
Follow me on Blue Sky