Somewhere in mid-2017 I started working on a Kotlin programming book, but then I had to get away from it to work on other things. When I got back to it recently I looked around and felt like the world didn’t need another “Introduction to Kotlin” book — there are a couple of good ones out there, including Kotlin in Action, and the kotlinlang.org documentation is excellent — so I decided to ditch the project completely.Back to top
Kotlin Quick Reference
But then when I started writing some Kotlin code again I realized that what I really needed was a quick reference. I didn’t want to have to dig through a tutorial book or website to find what I need, I just wanted something like a large cheat sheet where I could quickly find the Kotlin syntax and examples for whatever I was working on at that moment. So I decided to strip down what I had already written and create both a book and a Kotlin Quick Reference website.
The URL contains a statement of the Red Hat ethos. A couple of good quotes:
Open source is a development model, not a business model. Red Hat is in the enterprise software business and is a leading provider to the Global 500. Enterprise customers need products, not projects and it’s incumbent on vendors to know the difference. Open source projects are hotbeds of innovation and thrive on constant change. These projects are where sometimes constant change happens, where the development is done.
Here’s a link to Github’s 2017 Open Source Survey.
Here’s a link to Verizon’s open source Scala libraries.
These are a few notes on Apple’s Swift open source development project, taken from this mailing list post by Apple’s Chris Lattner:
- Open source is pretty great. It has been incredible to see such a vibrant community working so well together, and to see you come together practically overnight.
- Open source also brings challenges. I think it is fair to say that “open design” is slower and less predictable than “closed design”. However, the end result is significantly better, and therefore the tradeoff is worth it.
- Software scheduling (particularly with open source) continues to be difficult-to-impossible to predict.
- It is *good* to have high goals, but we need to do a better job of communicating that “goals” are not “promises” so that people don’t feel misled.
1) Don’t start with a wildly ambitious goal.
2) Don’t try to account for every scenario.
3) Don’t try to make it perfect.
4) Don’t try to be everything to everyone.
5) Don’t stop thanking contributors.
6) Don’t forget the documentation.
7) Don’t forget about the rest of your life.
8) Don’t forget to have some fun.
This blog post titled nanomsg postmortem and other stories is so good I wanted to share this part of it on “politics and technology.” The whole thing is a great read, as is this other article titled Requiem for Nanomsg. Both articles tell a fascinating story about software development, “politics,” and leadership.