joewalnes

Love OpenSCAD! Here’s a little library for generating “toy brick” compatible models for a 3D printer.

Also written to be a follow along example to help understand how to think about writing OpenSCAD programs.

https://github.com/joewalnes/toybrick

Bob was crazy. In the best way.

In the early 2000s, I first encountered Bob through the Java open source community. He had a knack of being able to go deep on a tough problem and emerge with a wonderfully elegant solution. This was a time when software was getting increasingly complex, and so did the knowledge required to understand it, yet Bob consistently bucked the trend and made things seems simple. He would tackle problems that scared others. He was crazy. Crazy Bob.

At one point we had a rivalry working on two open source projects competing to solve the same problem. When we first met face to face, I was nervous there may be confrontation, yet he was friendly, full of energy, and excited that we shared the passion for the same problem. We brainstormed many ideas and both went away feeling great! His crazy energy amplified my own and passion for software.

Shortly after, I joined Google because of Bob. Over the years since, he and I did our best to recruit each other for nearly every company either of us worked at - we just never got the timing right, yet I was always hopeful we'd figure it out eventually.

Even in CxO roles, whenever Bob and I met we'd geek out on all sorts of tech problems, ranging from API design, to embedded C firmware tricks, to financial protocols, to graph network theory, to hardware development. He loved tech, and his eyes lit up whenever we found a shared passion.

Bob was one of those few people who was incredibly smart, could see the problem in different ways, energize everyone around them, and make you want to be a better you.

Crazy Bob. You'll be missed.

JUnit ships with this method:

  void _dont_implement_Matcher___instead_extend_BaseMatcher_()

If you're interested in why: https://www.reddit.com/r/programming/comments/nlt5x/i_believ...

Details: https://aws.amazon.com/athena/faqs/

A very tiny shell script: https://github.com/joewalnes/go-getter

Like go get, but you specify exact versions, including transitive dependencies. One GOPATH per project. And most importantly, you don't have to use go get to install the tool in the first place.

Dave thanks for doing this. Not just for building the tool but for a very well thought out and convincing presentation.

I'm completely with you. My own solution has similar ideals (per project versioned deps) though a different solution. https://github.com/joewalnes/go-getter/blob/master/README.md. Honestly I'm just glad others are finally talking about the elephant in the room.

Very slick! Love seeing Python built games like this. Well done, sir.

Words cannot describe...

This is a slightly modified snippet extracted from something I wrote last year predicting the Google Code shutdown. https://medium.com/@joewalnes/some-2015-tech-predictions-1e7...

------------

It's not about Mercurial vs Git.

When Google Code added Mercurial support, Mercurial and Git were roughly equal in popularity. Git was more functional, but Mercurial was a lot simpler to use. In fact, almost everyone I spoke to at the time preferred Mercurial and honestly I thought it was going to be the winner. Project hosting sites that had typically used centralized source control systems like CVS or SVN scrambled to add Git and Mercurial support (including Google Code).

Then GitHub happened. They realized that the it's not just the source control system that should be decentralized but every aspect of the project. Projects could be forked with a single click, pull requests created and tracked, network graphs explored. It created an organic and discoverable open-source ecosystem, the likes of which we never saw on Google Code, SourceForge, etc. Anyone could explore ideas in existing projects without having to gain committer access. It was magical.

GitHub may have just as easily decided to bet on Mercurial instead. I believe if that would have happened, Mercurial would be the most widely used system today. BitBucket did something similar for Mercurial and did pretty well, but GitHub always had the lead.

It was the project hosting sites that lead the source control systems, not the other way round

So, back to Google Code. It could have been something huge and it could have made Mercurial the winner, but Google Code never grokked the importance of "social coding". Even though the source code was decentralized, the projects themselves were still centralized. Decentralized project concepts such as forking, network graphs, pull requests, etc - this was all from the new world of GitHub.

Over the past two years we've seen Google release new open-source projects on GitHub, then existing projects starting to migrate. Recently, Go started migration too — this is no casual move because it affects the import paths used in a vast amount of user created Go code which will build breakages. Yeah, the writing is on the wall for Google Code.

When SourceForge fell out of favor it was sold. It’s now filled with ads, especially deceiving ones on project downloads page which try to trick users into downloading some malware infested turd burner. In fact, for a while SourceForge were actively modifying genuine project releases to include spyware. Cocks.

Google didn't do a SourceForge. If there's anything we’ve learned from Google over the years is that they’re not afraid of shutting down projects that don’t work out. By the way, I really respect Google for this — killing products takes guts.

Google Code — I salute you. You did well, you made the open source world a better place, and above all you stepped aside when you knew the time was right.

Codehaus was the birthplace of many Java open-source projects last decade.

Enterprise Java was becoming mainstream, but the open-source community saw that it had much more potential than the tools provided by Sun.

Codehaus provides project hosting (source control, issue tracking, websites, continuous builds, downloads, mailing lists, IRC, etc). This was back before GitHub existed and the only other option was SourceForge (which was terrible).

But above all, Codehaus provided community. The developers across projects all hung out together, on mailing lists, IRC and the occasional global meetup. Respect and friendship. It was there that many gripes and problems were discussed and new projects were born.

If you've ever benefitted from Groovy, Jetty, Grails, Gradle, XDoclet, XStream, jMock, EasyMock, QDox, Drools, Esper, Mule, PicoContainer, Jackson, Janino, JBehave, Stomp (and hundreds others), this was thanks to the Codehaus community.

Many of the projects and people have gone on to do great things. Companies have been formed. New communities created. Many projects died, some thrived. Codehaus is no longer the hotness it once was, but it provided the foundation that many of us have benefitted greatly form, and it's no doubt one of the giants that the Java open-source community is standing on the shoulders of.

Codehaus is now shutting down: http://codehaus.org Please join me in raising your glasses to the people and projects. Codehaus, we salute you. So long, and thanks for all the fish.

Yes, I often have 10K plus processes running on a production server. It's caused troubles at time due to misbehaving processes, but mostly it's been ok. Linux is surprisingly good at this (wasn't always the case).

For the times when some of my processes were misbehaving, it was easy to identify which processes were misbehaving with "ps", "top", etc and resolve with "nice", "kill". This killed the bad connections without bringing the rest of the app down. Sysadmins like me.

websocketd treats each line as a message. i.e. boundaries are marked with \n

Yep. The only magic thing is a line break (e.g. \n) is used to terminate each message.

ed is for the weak. Real developers edit bits using the magnetic forces of oceans.

Didn't use any templates or frameworks (apart from font-awesome for icons and prism for syntax highlighting the code examples).

Just some good old fashioned hand written HTML + CSS. https://github.com/joewalnes/websocketd/tree/gh-pages

That indeed was a dilemma. Although it focusses on doing one thing well, there were also a few core things that are useful to support a websocket based app - namely a place to serve the actual web content from (static) and the ability to use websocketd using vanilla http instead of websockets (cgi).

It allows you to write a WebSocket end point, in any programming language, without having to deal with building socket servers, dealing with WebSocket protocol handshake/parsing/formatting/etc, worrying about threading etc. Just write a script that reads and writes to stdin/out.

Thanks. And I suck at naming stuff.

I've built chatrooms with websocketd. To do this, you a shared pub/sub store. Redis is great, so is Postgres (with its pub/sub add-ons). Storing chat data in a store is more durable than keeping it in memory on a single machine.

CGI fell out of favor for this reason, but WebSockets have a different runtime profile: instead of having to deal with 10K shortlived requests per second, WebSocket endpoints have much fewer but longer lived connections. This is why the CGI model actually works well on WebSockets.

Great to hear! Thanks :)

A philosophy is neither right nor wrong. It's a philosophy, one that you choose to subscribe to, or not.

WebSockets are message based.

I haven't used websocketify. I'd be interested to have users try out both and write up their experiences.

Nice! I hadn't seen that. Yeah, that's pretty sweet.

OP here. Something I forgot to mention on the page is how much this simplified life for a server admin. Using "ps" you can see each connection, the memory overhead, CPU usage. It's easy for a sysadmin to kill bad connections without taking down the whole server.

OP here. The overhead is really dependent on your process overhead. I typically use it for Python/Ruby/C apps which are relatively lightweight compared to something JVM based.

The runtime profile of WebSockets tends to be different to typical HTTP requests too. With typical HTTP you're often optimizing for 1000s of short requests per second, whereas with WebSockets the requests are much longer lived.

* Apple open-sources Swift compiler, open-source server-side ecosystem emerges

* Internet Explorer starts using an open-source rendering engine (like WebKit)

* Google Code shuts down

* Apple will NOT open up iPhone 6 NFC APIs

* Google self driving cars start a war in Washington

* Apple Watch gives life to "intimate" social networks

* Uber launches a package courier service

Some of these sound far fetched, but there's a slight method to the madness.

Rationale here: https://medium.com/@joewalnes/some-2015-tech-predictions-1e7...

Video demo: https://www.youtube.com/watch?v=AyCkmbqB7ko

Hulk Hogan