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.
1,235 karma · joined August 23, 2010
Also written to be a follow along example to help understand how to think about writing OpenSCAD programs.
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.
void _dont_implement_Matcher___instead_extend_BaseMatcher_()
If you're interested in why: https://www.reddit.com/r/programming/comments/nlt5x/i_believ...
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.
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.
------------
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.
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.
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.
Just some good old fashioned hand written HTML + CSS. https://github.com/joewalnes/websocketd/tree/gh-pages
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.
* 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...