I recently purchased a MacBook Pro. I was eagerly expecting a seamless setup experience.
The experience was not seamless. The good news is I have a working system. The bad news is it took a while to get here. I’m writing my experience to help others who may also be setting up a new Mac and trying to get things to work.
I kicked off NodeSummit today with a short talk about where Yahoo uses Node, why we continue to use Node, and the practices that help us use Node effectively.
First talk of the day.
I spoke a bit about a project I’ve spent the last year on: using Node to handle data pushed out of Jenkins. Folks appreciated the honesty about Jenkins’ user interface.
Jenkins is the solution that we trust, but nobody loves using it. At Yahoo, we use Node to help us make Jenkins a bit better to use:
- scripting job creation, editing, deletion
- handling log messages
- displaying information about builds with a web interface
During the talk I mentioned something called RDL.
Nope, not the Romanian Deadlift. It’s something we call “Resource Description Language”, a machine-readable spec for web APIs. We started using it for some internal deployment APIs we worked on last month. This spec is transformed into hapi route configurations that contain detailed joi validators.
What’s great about this is that when you change the RDL, it changes the validators and comments which we present using the lout module. We do this by merging together existing hapi route objects using the RDL spec as the source of truth, so the hapi routes we have in code are validator-free and require the RDL as the source of truth. This has worked very well and our spec always matches the reality. This works a lot better than other systems that actually generate source code from RDL, which is not ideal because it cannot stay in sync as your code changes.
It’s been fun! I’ll also be on the “Scaling Business Critical Node.js Applications” and “v0.12 and Beyond” panels tomorrow, so check those out if you’re attending NodeSummit.
Eran Hammer on Node.js web framework design tradeoffs and why there is no “best” framework:
If you haven’t read Netflix’s Node.js in Flames blog post you should. It is a great deep dive into debugging a node performance problem. The post includes useful tips that can help you solve similar problems.
My feedback from the perspective of a framework developer is quite different. I found the tone and attitude towards express.js to be concerning and somewhat offensive. Here was a developer blaming the framework he chose for poor architecture when they never bothered to actually learn how the framework works in the first place.
Recommended for understanding why Express works the way it does, what other frameworks do differently, and why none are superior to the other without considering your own requirements.
The fine folks at Sauce Labs invited me to speak at DeveloperWeek San Francisco about browser testing at Yahoo scale. We test YUI on IE 6, 7, 8, 9, 10, & 11, iOS 6 & 7, Chrome, Firefox, and Safari, which runs over 120,000 tests on every push.
We’ve learned a lot about how to spend our time and the challenges of CI testing with multiple browsers. I began with a introduction to Yeti, the easy way to get started with web testing, which also drives over a million automated tests every week for YUI.
Check out the slides from my talk. If you were there, thanks for being a great audience! There was a great turnout with smart questions.
If you are interested in working on our unique frontend to CI testing with me at Yahoo, get in touch.
Steve Klabnik considers “Is npm worth 26MM?”:
If you want to repeatably manufacture an open source ecosystem, you need capital to do so. And a firm that’s progressive enough to understand the indirect payoffs of investing in infrastructure is poised to have a huge advantage.
Less than a week since the last release and as promised, Yeti 0.2.27 has shipped today with code coverage support.
Yeti 0.2.27 provides first-class code coverage reporting provided by Istanbul.
Simply use Yeti with the
--coverage option. By default, Yeti will instrument your code on-the-fly and show a brief summary.
Yeti has ran 1,207,780 tests for YUI since Yeti 0.2.26 shipped 6 days ago.
I’m very excited to bring code coverage to yo/tests.
I’ve released a new version of Yeti, the test runner we use here on Yahoo’s YUI team. Since August 2013, Yeti has automated 33,661,505 tests in CI for us.
Today’s release prints useful feedback to stderr when Yeti is used in CI. It also includes a fix for issue #74 (Unable to serve error) and #68 (improve DOH support).
When using Yeti to in CI, e.g. to produce JUnit XML output, previous versions of Yeti would go silent after testing began as Yeti produced XML output on stdout. This made it difficult to determine if Yeti was doing anything while tests ran. When using Yeti with
--junit, today’s release prints status after every test completion to stderr while XML prints to stdout.
Big thanks to @henryqdineen for contributing the fix for DOH support!
In addition to fixing bugs, we have made some improvements to Yeti’s own tests and to Yeti’s documentation. Yeti’s website now uses Pure for your viewing pleasure on desktop and mobile devices.
Expect more updates soon. Code coverage is next on my list.
Facebook engineer Jason Barrett Prado answers the question What was it like to help develop Paper?
Paper was designed on a principle: content should be respected. Facebook is supposed to be like a glass through which you can see its contents. This has been an aspirational goal for a long time, but in reality many of the pixels on the screen in our products are not content, they are chrome.
If we are trying to respect content, we should minimize chrome in a radical way. Everything on screen should be a user’s content, whether it’s their picture, their name, their posts, or their photos. Paper has almost nothing on screen except for user-generated content.
[…] Facebook can be beautiful, but I feel that the design of previous Facebook products does not inspire users to create and post beautiful content. I hope that Paper does.
Don’t miss the details on Facebook vs. Apple culture, the team’s experiments with organizing content, and the challenge of rendering animations on multiple threads.