7 August, 2016
Recently I gave a talk at SQL Saturday Baton Rouge on the history of the Web. This was a version of a talk I had given many times before, largely to codecamp classrooms of novice developers. In sexing it up for a professional technical crowd, I ended up rewriting it completely - going back to a lot of primary sources, reading the www-talk archives and the various books written by people who were there at the time (Side note: a surprising amount of these individuals feel a need to include sections in their articles on the particular type of food and entertanment had at w3c conferences. It’s…weird.) In doing all this research to get an understanding of how it is that we got where we did, I ended up forming some opinions on where we’re probably going.
In this blog post series I’m going to make some hopefully non-obvious predictions about the future of the world wide web and how it is that we got here.
15 July, 2016
So we want a fully functioning tab system with url navigation. Lets figure out how to do that.Comments
14 July, 2016
During an interview, a candidate - a smart guy just at the start of his career - asked me the following (paraphrased)
I feel like the biggest hole in my understanding at this point is how applications work at scale. How does one put together a large application with millions of users and hundreds of thousands of data connections? How does one process big data and use map/reduce. How do I advance myself in that area?
I’ve heard similar questions before. Heck, at some point I probably asked them myself. So let me answer this here, in blog format.
That is not your biggest hole. Honestly, it’s hardly a hole. Hardly anyone actually has to work with applications “at scale”. Maybe if you work at Netflix, and even then, the only person who really works at that level is named Magnus, has an office on the top floor and can read bit streams raw.
That’s not going to be you in the near future and, chances are, not going to need to be your skillset at all. It is simply not where you should invest your time.
You, my dear codecamp graduate, need practice working with others.
Not in an interpersonal sense (although maybe), but in the sense of how to write your code so that others can read it and maintain it. And that’s not just code comments. That’s design patterns, software architecture, project management, and just plain ol’ experience in getting-things-done. You need experience estimating, selecting proper technologies, and helping clients figure out that what they think they want is not what they need, and talking them into allowing you that extra week of refactoring.
In short you need practice coding. And coding with other people. Lots and lots of practice.
It’s hard of course. You’ve been focused on learning for so long with a side of implementation and now its time to see-saw in the other direction. The easier route is of course to just keep taking lessons and schooling and learning, but what I’m saying is its time to start getting those ten thousand hours in.Comments
14 February, 2016
I’m putting together a workshop on estimation of large projects and features for the Operation Spark coding bootcamp and ended up mind mapping several dozen always-make-sure-to-discuss-this rules of thumb. I figure, why keep this private? I have plenty of experience but that’s still just me. Let’s open it up for public contribution.
So here is a github repo. It contains a simple
.mdfile so you can edit it entirely in-browser. Fork, edit, and give me a PR to share your experience!
18 October, 2015
So here’s the thing that’s always confused me about
display: inline-block. Let’s say you have two subsequent
inline-blockelements. If the container has no padding, and the elements have no margin or border, and if you set both those elements to
width: 50%then they should appear side-by side, right?
I’ll assure you that the previous paragraph’s logic checks out. So what is going on then? Why do these elements appear on different lines? I’ve wondered this for years always just setting
width: 48%and chalking it all up to an inconsistency in my understanding of how css layouts work.
Finally, with some help from StackOverflow I’ve got it. And as wierd as it is, it makes sense!Comments
- 12 Sep Talk Roundup - Be the Es6iest
- 27 Aug Automated Testing Venn Diagram
- 03 Jul Learn reduce
- 08 Jun Color Mixing Demo App
- 06 May Some self-indulgence from the nolatech chat
- 01 May Why Not MsTest
- 20 Apr Stop teaching h tags
- 19 Feb node-gyp won't install on Windows
- 31 Oct Use Simple Modules To Fix Up Your Ugly Brownfield App 1
- 29 Apr On this and new
- 09 Oct Open IIS Express to the Network
- 26 Sep Setting Up RequireJs
- 29 Apr Stop that = this'ing
- 16 Jan Error Handling and the Message Repackaging Anti-Pattern
- 12 May QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture