Manually marshalling/unmarshalling JSON has been a pain point for me on recent projects. I took a quick look at Protocol buffers just now and instantly understood how that will solve most of my issues with JSON. I define a simple message format (.proto) and generate native classes. My service methods can use the generated classes as parameters.
The only thing missing for me was native support for JS (but I quickly found 3rd party libraries).
I don't quite understand how transit, since it's schema-less, addresses that problem. From transit-java docs:
Object data = reader.read();
I might be missing something, but it seems I have to manually create the native classes on both endpoints and cast to those classes. Either that or I still have to manually extract values using the reader API.
W3Schools is the site programming hipsters love to hate... after they've discretely used it to get going in their programming.
A lot of people also use it to get going in their design careers.
It was the original widely used instant evaluation site (you can type some code into an evaluator and see the result).
Hilariously, the main W3Schools hate site, W3fools.com, is one of the truly most horrendous looking sites I've ever seen. That site would have been considered horrendous in 1996, much less now. It shows that the detractors of W3Schools are just insecure hair splitting code nuance boffins totally out of touch with what a lot of people need to do in their day to day work.
I'm not affiliated with W3Schools in any way, other than having been a happy user for quite some time, along with MDN and all the other good resources.
The people who spend their time hating W3Schools are most likely the conceited bastards at work who inject two second pauses into their expressionless answers for questions from the new programmers.
The people who haven't decided hating W3Schools is worth a lot of time are probably those nice people at work who deduce what a new programmer is needing, and happily line you out with enthusiasm.
Your irrelevant personal attacks against people who have legitimate gripes with W3Schools do not convince me that it's the "nice people" who like that site. Seriously, how is making rude comments about people based on their taste in learning resources meant to demonstrate that W3Schools is a good resource?
While I'm still chewing on the general premise... I have to say I really like the way the author quantified the involvement of the various parties involved in chef. That took some work and is useful, so I'm impressed.
> Additionally having the code on GitHub gives a nice warm and fuzzy feeling that there is no vendor-lock-in, even though there is no other game in town.
What about puppet and/or ansible? Is there something chef does they don't? I haven't been keeping up with their relative capabilities, but last I checked they were somewhat comparable. I don't know how open source puppet and ansible are, either.
While I disagree with the premise of the blog post above and companies should be able to decide how to run themselves, I will say Ansible was one of the top 5 projects for most OSS contributors on GitHub last year (up there with Rails, Angular.js, and Homebrew). We have over 775 total contributors now.
I think the greatest benefit of contributors is how to learn from them, creating a fantastic commons of learning, and they also keep things really well polished. Ansible was built to build this commons out, and we have some 235+ modules in core because of this now, collectively maintained.
But there are also some things that community engineering has a hard time building, and that's ok. This model doesn't work for all things, and employing a lot of really sharp people and giving away code is totally great too. Distributed systems can be one of those things. Crypto can be one of those things. These are things that don't need as large of teams as "make this systems component work on every version of Linux/Unix/Windows/other".
I don't think there should be a sense of entitlement towards everything being 100% democratic - it's not appropriate everywhere - but when you can make it work, it can be a good thing. In cases where the code is still open, but it's a little harder to contribute to, it's still open and you can learn from those sources and patch them when you need to. Editorial inputs are still important. Having a larger vision is critically important.
When those forces and needs can be balanced, great! OSS is about itch scratching, so sometimes if you want to build something when others have different itches (or customers do), you do have to just go out and direct some folks to build it. And that direction may be different than a whole armada of people may want to go, but can still get you to very interesting destinations.
For us, I think it's about alternating between those two modes - enabling the stream of "everything" to come in from GitHub (but filtering it, reviewing it, and making it better), but also remembering where we might like to go, and pointing that way, and building some of those bridges to make colonization of new areas possible.
I think characterizing discussion of the effects of facebook on oculus as 'Facebook hating' is a pretty cheap dodge of a significant event. A lot of the strategy changes people are making around the facebook purchase are legitimate ones based on reasonable observations of facebook. It's a terrible thing for those of us who were really excited about oculus for so long, but things changed and a reasonable discussion is going to happen.
I think that the argument that facebook adding "tacky social media" components to oculus would be bad for business is incorrect. Facebook has done quite well with the model, as their company shows.
For many of us, we realize that facebook will likely succeed with oculus in some way. It will just be a different kind of party than we want to go to, is all.