Category Archives: Shared Articles

Designers will design, developers will develop, and why you must stop them

Leave a reply

Designers will design, developers will develop, and why you must stop them

In February 2014, I made a recommendation to my co-founders at Ballistiq that I wanted to cancel development of ArtStation. The project was in development hell. It wasn’t going anywhere. I was unhappy with it and just couldn’t see a path for it to be a successful product. Two months later we managed to launch it, and two years later it is the leading network for professional games, film, media & entertainment artists with over 2 million users per month, leading studios recruiting on the site, an official Star Wars competition running and great opportunities.

What happened? Why did I want to kill the product before it even made it to market? Unfortunately, I had allowed development to spiral out of control. We were far behind schedule with a product I had allowed to become too complex. Whenever I needed a change that should have taken 5 minutes, it took days or even weeks. Over budget, burned out and frustrated with everything and everyone, I just wanted to kill it and move on.

Getting excited

As an entrepreneur of a startup, you have to sell people a dream. The product doesn’t exist yet, so you’re selling an idea that it will somehow transform something/someone/some industry, bring fame and fortune (hopefully).

The first few people we recruit are important. We hype them up and sell them on the dream. Everyone is excited and wants to give it everything they’ve got.

When we started the ArtStation project, everyone was super excited about it. We were going to transform the art industry with our awesome portfolio builder + social network. We held validation waves and got tons of feedback. The designers and developers I had brought on the project went full throttle creating the product.

Designers will design

Designers are always going to design. We love to create things. We love to innovate.

The problem with designing for something that doesn’t exist yet is that the constraints aren’t real. You’re coming up with stuff that make people go “WOW that’s awesome!”

The first version of ArtStation that we ended up creating was a marvel of design. Every single icon was custom designed and crafted. Inputs had no labels on them. The UI was “cutting edge” and “innovative”. The mockups looked sexy as hell.

However, this combination of talent, obsessive nature, excitement about the project and going the extra mile also created a complete nightmare to work with. Because icons were custom designed, every time we needed a new icon, we had to ask the designer to create a new one. Because he’s obsessive about his work and wants to give it 120%, he spends hours on a single icon. At this point, ArtStation is also regarded a side project and our agency business is the priority, so he has to do this in his spare time. Getting a new icon would take days if lucky, usually weeks. If we had used a pre-made icon kit like FontAwesome, we would have just chosen an icon and that was it. 30 seconds of work — not days.

The “innovative” designs that were “boundary pushing” were also practically unusable in real life. Because many of the components were completely new, our developers had to implement them. The problem is that anything you develop will generally suck in its first version. Things won’t work correctly. And there are always nasty edge cases that you didn’t think about.

That’s exactly what happened. The interface just didn’t work properly — inputs were practically impossible to use because there were no labels, many components failed when the screen wasn’t the size that the designer intended. Everything looks good and works perfectly on a Photoshop mockup and InVision prototype, but in real HTML it looks and works terribly.

After spending months and tens of thousands of dollars, the UI was a disaster. If we had just stuck to tried-and-true UI components and workflows (like the ones in Bootstrap) the product would have actually shipped. Instead we had a hunk of sexy, unusable turd.

Was it the designers fault? No. It was my own stupid fault.

I didn’t want to be the buzzkiller. I had sold the dream. I couldn’t bear to tell him — “Dude this won’t work” or “Dude this design is going to take 10x longer to make than just using Bootstrap components and FontAwesome icons. We’re not doing this.” I wanted to be the cool boss that allowed for innovation. I wanted to be the cool boss that allowed the team to try something and fail. The problem was that I couldn’t afford to fail. I’d blown tens of thousands of dollars and was nowhere closer to shipping a product.

Developers will develop

It’s not just designers. Developers will go the extra mile and drive off a cliff as well. Developers are creative. We’ll do our best to come up with solutions for problems that don’t exist yet (but they might!). We’ll engineer things so that if your product scales, you won’t have to worry about it. And we’ll custom build you things as well because the off the shelf stuff doesn’t exactly work the way that your product does.

The developers on ArtStation are all highly talented and motivated. But again, I didn’t provide enough constraints and it spiralled out of control.

Our front-end developer wrote the entire front-end CSS from scratch. He had decided that using a framework like Bootstrap was excessive because we wouldn’t be using 90% of the components in it. The problem is that when you develop something new, it hasn’t been production-proven. The CSS was problematic. It didn’t work well responsively. There were weird edge cases. And whenever we needed to add new things, like a table or another kind of input or button, we’d find ourselves with no styles for that component, so we’d have to go back to him and it would take days to get the component styled, but then it wouldn’t work properly the first time or we’d find weird edge cases, and have to iterate again.

Our backend developers had fallen off the rails as well. They wrote a services layer on ArtStation, citing best practices. Yes, I accept that a services layer (or service objects) is good. But we’re trying to ship a freaking product here and the architecture they created was excessive. It had deviated from standard Ruby on Rails far enough that the project had very high technical debt. When I put other Ballistiq devs on the project, they’d freak out, kick and scream at why this was so far off “the Rails way”. And the architecture was buggy as hell. Again, when you create something from scratch, it generally always sucks at first.

Was it the developers fault? Again, no. It was my own stupid fault again. I had allowed the developers to dictate to me the “best practices” and I had allowed them to go their merry way, which meant many sprints iterating on perfecting the architecture but not actually shipping the product. I failed to communicate the real business and time constraints and acquiesced to their push back, wanting to create beautiful code. I didn’t want to be the boss that said, “Dude — you’re writing stuff that we can just solve using standard Ruby on Rails and gems —please don’t rewrite the freaking wheel”.

Crawling out of that hole

In February 2014, I was burned out. The project was going nowhere. Behance had been acquired by Adobe. DeviantART got $10m from Autodesk. Other startups were getting funded building similar things to ArtStation. I knew that ArtStation would likely just get squashed by these bigger players. I wanted to just cut our losses and move on. I made a recommendation to my co-founders that I wanted to shut down ArtStation. My partners looked at me stunned and asked me to take a break for a few weeks. I took everyone off the project, telling them we were going to take a break for a few weeks.

Then, being the obsessive workaholic that I am and unable to sleep at night knowing that I’m a quitter, I decided to give it one last shot. I rolled up my sleeves and dove in.**

Because our designer was busy working on agency projects, I no longer had a designer to fix all the issues we were having. I redesigned the entire interface using standard, tried and true (non-innovative) components. I designed with technical constraints in mind. I spent very little time in Photoshop just to get the overall design direction.

Then I moved quickly into HTML, scaffolding the entire application in Bootstrap and making design decisions with real HTML. I had to throw out all the CSS the previous freelance front-end developer had created. I simplified the design significantly. Icons were from FontAwesome. Literally months of painstaking work by a team of people were thrown out in favour of simpler, less sexy things that would get the product shipped.

A week later, I had a working prototype of the new ArtStation.

I had to confront the front-end developer. He got pissy and complained that my front-end was bloated. We exchanged words. Ok. Bad fit for the project.

I had to explain to my designer about why his designs were changed. He understood. He appreciated the business reasons and was happy with the new progress.

I had to confront the backend developers about complexity. We wrestled with it. Compromises had to be made between creating beautiful architecture and meeting business objectives.

It was a very challenging time, but we got through it. In March, I flew to Los Angeles with my co-founder. We showed ArtStation to many artists and studios and universally got positive feedback. In April, a competitor went out of business. We launched, we kicked ass and have been ever since.

Context, transparency and being a hardass

The biggest lesson that I learned was that you have to provide context and be transparent. When talking to my team, I should have given a lot more context about the constraints of the project. We really couldn’t afford the time and cost overruns. We needed things to be as “off-the-shelf” as possible so that we could ship the product.

I also needed to be a hardass and confront issues early. I had to not be afraid of confronting a team member. I had to be more comfortable with being a buzzkill on the team, even if it meant driving away talented devs and designers that just weren’t a good fit to begin with.

It’s still a gut wrenching experience. Whenever I see a new design and I have to tell my designer, “Dude I love your design but we can’t make this.” and he pleads with me, “Please can we just try it out?”, and I respond, “No man, this will take weeks to prototype and by the time we’ve invested that we won’t want to throw it out and want to spend more time iterating on it.” I can see the disappointment in his eyes. I can feel the excitement rushing out of him. I have visions that he’ll want to leave for some stupid startup with millions in funding where they can afford to iterate on nothing.

Being boss isn’t easy. There are no easy answers.

Today, I couldn’t be happier with what we’ve achieved with ArtStation. The team has grown together. We bicker and banter sometimes, but we get it.

Ship the freaking product.

Addendum added Thursday 26th May 2016:

Thanks to everyone for recommending the article. I was truly not expecting this article to become such a big hit and that so many people had experienced the same pains.

I’ve had to edit some parts of the article and a footnote to clarify some things.

** This section was not about heroics. The necessary people on the team were kept in the loop. The designer had already been re-assigned to other agency projects and wasn’t available to continue working on the project. One freelance developer with NIH syndrome was intentionally sidelined so that we could unblock the rest of the team. Just wanted to clarify. Also do read Robert Monfera’s response as it has some great points.

Let's block ads! (Why?)

You don’t learn anything from drafts

Leave a reply

You don’t learn anything from drafts

Why you should publish more content, more often.

Whether it’s a blog post, a video, a podcast or any type of content. Hitting publish can be extremely daunting.

You can worry how others may react to it. You can worry it’s not polished enough. Or that it might fail. But, one of the of the most important lessons I’ve learned since I started writing is simply:

You don’t learn anything from drafts.

When you put yourself out there and embrace the vulnerably, that’s where the magic happens. That’s where you learn and improve your craft.

And the great thing about shipping content is that the more frequently you publish, the easier it gets. Eventually, making content becomes less of a “big” thing, and a part of your workflow. Then your mindset changes from:

“This is a special moment”

to

“This is what I do: I create, I publish, I put things out there.”

Play the long game.

Creating content is much like going to the gym. You don’t expect to work out once or twice and see the results you’ve always dreamed of. But once going to the gym becomes a part of your routine — and not a one off event — you start to see results.

The same is true in publishing — no matter your field. When you’re publishing and creating regularly, you are lifting those weights and eventually you’re going to build muscle mass, but if you expect it to happen in a day or a week or a month you’re kidding yourself.

The practice is really the key and that’s what you should be focused on, not the instant outcome or result.

If you only focus on results, it’s easy to give up. But when you focus on the practice and routine, it becomes easy to keep going.

Along the way you have to expect that you’re going to have many failures and a few successes, but the most important step is hitting publish. You don’t learn anything from drafts.

For more content check out Frontcourt Magazine

Read next:

Let's block ads! (Why?)

You don’t learn anything from drafts

Leave a reply

You don’t learn anything from drafts

Why you should publish more content, more often.

Whether it’s a blog post, a video, a podcast or any type of content. Hitting publish can be extremely daunting.

You can worry how others may react to it. You can worry it’s not polished enough. Or that it might fail. But, one of the of the most important lessons I’ve learned since I started writing is simply:

You don’t learn anything from drafts.

When you put yourself out there and embrace the vulnerably, that’s where the magic happens. That’s where you learn and improve your craft.

And the great thing about shipping content is that the more frequently you publish, the easier it gets. Eventually, making content becomes less of a “big” thing, and a part of your workflow. Then your mindset changes from:

“This is a special moment”

to

“This is what I do: I create, I publish, I put things out there.”

Play the long game.

Creating content is much like going to the gym. You don’t expect to work out once or twice and see the results you’ve always dreamed of. But once going to the gym becomes a part of your routine — and not a one off event — you start to see results.

The same is true in publishing — no matter your field. When you’re publishing and creating regularly, you are lifting those weights and eventually you’re going to build muscle mass, but if you expect it to happen in a day or a week or a month you’re kidding yourself.

The practice is really the key and that’s what you should be focused on, not the instant outcome or result.

If you only focus on results, it’s easy to give up. But when you focus on the practice and routine, it becomes easy to keep going.

Along the way you have to expect that you’re going to have many failures and a few successes, but the most important step is hitting publish. You don’t learn anything from drafts.

For more content check out Frontcourt Magazine

Read next:

Let's block ads! (Why?)

You don’t learn anything from drafts

Leave a reply

You don’t learn anything from drafts

Why you should publish more content, more often.

Whether it’s a blog post, a video, a podcast or any type of content. Hitting publish can be extremely daunting.

You can worry how others may react to it. You can worry it’s not polished enough. Or that it might fail. But, one of the of the most important lessons I’ve learned since I started writing is simply:

You don’t learn anything from drafts.

When you put yourself out there and embrace the vulnerably, that’s where the magic happens. That’s where you learn and improve your craft.

And the great thing about shipping content is that the more frequently you publish, the easier it gets. Eventually, making content becomes less of a “big” thing, and a part of your workflow. Then your mindset changes from:

“This is a special moment”

to

“This is what I do: I create, I publish, I put things out there.”

Play the long game.

Creating content is much like going to the gym. You don’t expect to work out once or twice and see the results you’ve always dreamed of. But once going to the gym becomes a part of your routine — and not a one off event — you start to see results.

The same is true in publishing — no matter your field. When you’re publishing and creating regularly, you are lifting those weights and eventually you’re going to build muscle mass, but if you expect it to happen in a day or a week or a month you’re kidding yourself.

The practice is really the key and that’s what you should be focused on, not the instant outcome or result.

If you only focus on results, it’s easy to give up. But when you focus on the practice and routine, it becomes easy to keep going.

Along the way you have to expect that you’re going to have many failures and a few successes, but the most important step is hitting publish. You don’t learn anything from drafts.

For more content check out Frontcourt Magazine

Read next:

Let's block ads! (Why?)

Twitter could be the next Mozilla

Leave a reply

Twitter could be the next Mozilla

Are you old enough to remember Netscape, the company that created the world’s first commercial web browser and server?

Even if you never did use the products, you’re probably familiar with some of Netscape’s lasting contributions to the web such as the JavaScript language, the SSL security protocol, or the <img> tag… And it’s likely that you have at some point used the open source successor to Netscape’s browser, Mozilla Firefox.

Netscape started life as Mosaic Communications Corporation. (In fact, their 1994 web site is still online and worth a look!) The company changed its name to avoid conflict with the older NCSA Mosaic browser. In August 1995 Netscape was listed on the NASDAQ stock exchange, saw its stock shoot up nearly threefold in the first hours of trading, and ended the day with a market cap of over $2 billion — unheard of (at the time) for a company with no profits. Netscape was the original blockbuster Internet company before Amazon, Google or Facebook.

The fall of Netscape was almost as meteoric as its rise. Microsoft started pouring money into browser development and bundled Internet Explorer for free with Windows, thus killing the market for a commercial browser. The server product also faced heavy competition, especially from the free Apache server project. Having lost its revenue streams, Netscape first made its browser open-source in an attempt to counter Microsoft’s R&D juggernaut, then finally in late 1998 ended up being bought by AOL in a stock deal that was worth $10 billion when the deal was consummated. Netscape stockholders were presumably pleased, although nobody else really was in the end.

The open-sourced Mozilla browser continued life under AOL/Netscape’s auspices. When AOL lost interest in the Netscape/Mozilla browser some years later, the project was spun off into the non-profit Mozilla Foundation. That coincided with a turn in fortunes for the browser as Microsoft’s Internet Explorer development stagnated for years, opening a window for Mozilla’s browser (in a lean edition newly christened Firefox).

Today, the Mozilla Foundation is a core player on the open web. As a non-profit, it provides an important balance against the interests of the three giant corporations — Google, Apple and Microsoft — that own the other remaining web browser engines. Mozilla also develops many other projects, some unsuccessful and frankly lacking purpose (Firefox OS), some offering important solutions to hard technical problems (the Rust programming language). The web without Mozilla would be much poorer today.

What does all this have to do with Twitter? The social media company today looks much like Netscape did in 1998. Twitter was one of the original social media pioneers, but it hasn’t reached the same level of global growth as Facebook. Twitter’s core product has stagnated while the company’s R&D seems to fritter away into entirely separate apps like Vine and Periscope. (At Netscape, executives wanted the company to make a “groupware suite”, not just a browser. Twitter’s lack of focus seems to be in a similar vein.)

Like the browser, Twitter actually provides an important infrastructure service on the modern Internet. It’s just not clear whether that alone has the makings of a growth-oriented public company. In the case of Netscape, the answer ended up being “no”. With Twitter, the answer is also increasingly looking like “no”.

Latest news (as of 14 October 2016) suggest that Twitter is not going to be acquired: Salesforce was openly interested but has apparently given up on any deal, and other rumored suitors disclaimed their interest weeks ago.

Where does that leave Twitter? The company will of course continue to exist, but it’s hard to imagine its stock price recovering soon. Twitter Inc.’s revenue is growing, but it has been constantly losing about half a billion dollars a year. New management will have to make deep cuts to bring the company to profitability. That kind of profit-oriented downsizing can easily become a vicious cycle that will end up destroying what’s good about Twitter-the-product today.

Twitter would deserve a more positive path forward, and Mozilla’s example provides one example to follow. Spin off the core of the platform into a non-profit, a “Tweetzilla Foundation”. Let the unleashed tweet streams become an essential piece of communications infrastructure on the web. Open up the APIs which Twitter-the-company closed years ago while trying to force users away from third-party clients (this was done so that ads could be served more easily, but it created lasting bad will towards Twitter in the developer communities).

Meanwhile the for-profit company — let’s call it “Twitter Media Inc.” — should focus on building the best damn consumer experiences on top of the tweeting platform. Double down on live streaming and other media experiences that benefit from Twitter’s real-time feedback. Make the ad platform so compelling that third-party Twitter clients will want a share of the action. This is what Google does with its AdSense program: it serves ads on millions of websites, yet it doesn’t need to control the web itself.

Yes, Twitter Media would be a smaller company than present-day Twitter, and getting Tweetzilla Foundation off the ground would be difficult (current Twitter’s cost of operations is probably tremendous). But it’s a more positive vision for the future than seeing Twitter Inc. shrink into a sad kind of operation that tries to wring increasing profits from the hardcore users of a closed social network.

The board of the current publicly listed Twitter Inc. might not approve of any non-profit spin-off — but what if Twitter went private? As its stock price sinks, the price tag becomes more palatable. Steve Ballmer has a well-documented interest in Twitter and owns about 5% of the company. A dedicated visionary with very deep pockets like Ballmer’s could conceivably make an offer for Twitter’s entire stock, take the company private, and then create the Foundation.

As a business endeavor this would not be immediately profitable. But for someone looking to make his mark on the Internet’s history, it might have a unique appeal. (He could simply call it the “Ballmer Foundation”, just to make it more obvious.) And the private Twitter Media could still become a highly profitable company eventually.

It’s a pretty crazy scenario. I’m using Ballmer here as an extreme example of how even a private investor could potentially turn Twitter into something much more important than it currently is.

Any such path needs to start with a vision, though. If you like Twitter, why not share yours in the comments?

Let's block ads! (Why?)

You don’t learn anything from drafts

Leave a reply

You don’t learn anything from drafts

Why you should publish more content, more often.

Whether it’s a blog post, a video, a podcast or any type of content. Hitting publish can be extremely daunting.

You can worry how others may react to it. You can worry it’s not polished enough. Or that it might fail. But, one of the of the most important lessons I’ve learned since I started writing is simply:

You don’t learn anything from drafts.

When you put yourself out there and embrace the vulnerably, that’s where the magic happens. That’s where you learn and improve your craft.

And the great thing about shipping content is that the more frequently you publish, the easier it gets. Eventually, making content becomes less of a “big” thing, and a part of your workflow. Then your mindset changes from:

“This is a special moment”

to

“This is what I do: I create, I publish, I put things out there.”

Play the long game.

Creating content is much like going to the gym. You don’t expect to work out once or twice and see the results you’ve always dreamed of. But once going to the gym becomes a part of your routine — and not a one off event — you start to see results.

The same is true in publishing — no matter your field. When you’re publishing and creating regularly, you are lifting those weights and eventually you’re going to build muscle mass, but if you expect it to happen in a day or a week or a month you’re kidding yourself.

The practice is really the key and that’s what you should be focused on, not the instant outcome or result.

If you only focus on results, it’s easy to give up. But when you focus on the practice and routine, it becomes easy to keep going.

Along the way you have to expect that you’re going to have many failures and a few successes, but the most important step is hitting publish. You don’t learn anything from drafts.

For more content check out Frontcourt Magazine

Read next:

Let's block ads! (Why?)

Twitter could be the next Mozilla

Leave a reply

Twitter could be the next Mozilla

Are you old enough to remember Netscape, the company that created the world’s first commercial web browser and server?

Even if you never did use the products, you’re probably familiar with some of Netscape’s lasting contributions to the web such as the JavaScript language, the SSL security protocol, or the <img> tag… And it’s likely that you have at some point used the open source successor to Netscape’s browser, Mozilla Firefox.

Netscape started life as Mosaic Communications Corporation. (In fact, their 1994 web site is still online and worth a look!) The company changed its name to avoid conflict with the older NCSA Mosaic browser. In August 1995 Netscape was listed on the NASDAQ stock exchange, saw its stock shoot up nearly threefold in the first hours of trading, and ended the day with a market cap of over $2 billion — unheard of (at the time) for a company with no profits. Netscape was the original blockbuster Internet company before Amazon, Google or Facebook.

The fall of Netscape was almost as meteoric as its rise. Microsoft started pouring money into browser development and bundled Internet Explorer for free with Windows, thus killing the market for a commercial browser. The server product also faced heavy competition, especially from the free Apache server project. Having lost its revenue streams, Netscape first made its browser open-source in an attempt to counter Microsoft’s R&D juggernaut, then finally in late 1998 ended up being bought by AOL in a stock deal that was worth $10 billion when the deal was consummated. Netscape stockholders were presumably pleased, although nobody else really was in the end.

The open-sourced Mozilla browser continued life under AOL/Netscape’s auspices. When AOL lost interest in the Netscape/Mozilla browser some years later, the project was spun off into the non-profit Mozilla Foundation. That coincided with a turn in fortunes for the browser as Microsoft’s Internet Explorer development stagnated for years, opening a window for Mozilla’s browser (in a lean edition newly christened Firefox).

Today, the Mozilla Foundation is a core player on the open web. As a non-profit, it provides an important balance against the interests of the three giant corporations — Google, Apple and Microsoft — that own the other remaining web browser engines. Mozilla also develops many other projects, some unsuccessful and frankly lacking purpose (Firefox OS), some offering important solutions to hard technical problems (the Rust programming language). The web without Mozilla would be much poorer today.

What does all this have to do with Twitter? The social media company today looks much like Netscape did in 1998. Twitter was one of the original social media pioneers, but it hasn’t reached the same level of global growth as Facebook. Twitter’s core product has stagnated while the company’s R&D seems to fritter away into entirely separate apps like Vine and Periscope. (At Netscape, executives wanted the company to make a “groupware suite”, not just a browser. Twitter’s lack of focus seems to be in a similar vein.)

Like the browser, Twitter actually provides an important infrastructure service on the modern Internet. It’s just not clear whether that alone has the makings of a growth-oriented public company. In the case of Netscape, the answer ended up being “no”. With Twitter, the answer is also increasingly looking like “no”.

Latest news (as of 14 October 2016) suggest that Twitter is not going to be acquired: Salesforce was openly interested but has apparently given up on any deal, and other rumored suitors disclaimed their interest weeks ago.

Where does that leave Twitter? The company will of course continue to exist, but it’s hard to imagine its stock price recovering soon. Twitter Inc.’s revenue is growing, but it has been constantly losing about half a billion dollars a year. New management will have to make deep cuts to bring the company to profitability. That kind of profit-oriented downsizing can easily become a vicious cycle that will end up destroying what’s good about Twitter-the-product today.

Twitter would deserve a more positive path forward, and Mozilla’s example provides one example to follow. Spin off the core of the platform into a non-profit, a “Tweetzilla Foundation”. Let the unleashed tweet streams become an essential piece of communications infrastructure on the web. Open up the APIs which Twitter-the-company closed years ago while trying to force users away from third-party clients (this was done so that ads could be served more easily, but it created lasting bad will towards Twitter in the developer communities).

Meanwhile the for-profit company — let’s call it “Twitter Media Inc.” — should focus on building the best damn consumer experiences on top of the tweeting platform. Double down on live streaming and other media experiences that benefit from Twitter’s real-time feedback. Make the ad platform so compelling that third-party Twitter clients will want a share of the action. This is what Google does with its AdSense program: it serves ads on millions of websites, yet it doesn’t need to control the web itself.

Yes, Twitter Media would be a smaller company than present-day Twitter, and getting Tweetzilla Foundation off the ground would be difficult (current Twitter’s cost of operations is probably tremendous). But it’s a more positive vision for the future than seeing Twitter Inc. shrink into a sad kind of operation that tries to wring increasing profits from the hardcore users of a closed social network.

The board of the current publicly listed Twitter Inc. might not approve of any non-profit spin-off — but what if Twitter went private? As its stock price sinks, the price tag becomes more palatable. Steve Ballmer has a well-documented interest in Twitter and owns about 5% of the company. A dedicated visionary with very deep pockets like Ballmer’s could conceivably make an offer for Twitter’s entire stock, take the company private, and then create the Foundation.

As a business endeavor this would not be immediately profitable. But for someone looking to make his mark on the Internet’s history, it might have a unique appeal. (He could simply call it the “Ballmer Foundation”, just to make it more obvious.) And the private Twitter Media could still become a highly profitable company eventually.

It’s a pretty crazy scenario. I’m using Ballmer here as an extreme example of how even a private investor could potentially turn Twitter into something much more important than it currently is.

Any such path needs to start with a vision, though. If you like Twitter, why not share yours in the comments?

Let's block ads! (Why?)

Closing cycles

Leave a reply

Closing cycles

One always has to know when a stage comes to an end. If we insist on staying longer than the necessary time, we lose the happiness and the meaning of the other stages we have to go through.
 Closing cycles, shutting doors, ending chapters — whatever name we give it, what matters is to leave in the past the moments of life that have finished.

You can tell yourself you won’t take another step until you find out why certain things that were so important and so solid in your life have turned into dust, just like that.
 But such an attitude will be awfully stressing for everyone involved: your parents, your husband or wife, your friends, your children, your sister.
 Everyone is finishing chapters, turning over new leaves, getting on with life, and they will all feel bad seeing you paralyzed. .

Things pass, and the best we can do is to let them really go away (however painful it may be!).

Everything in this visible world is a manifestation of the invisible world, of what is going on in our hearts — and getting rid of certain memories also means making some room for other memories to take their place.
 Let things go. Release them. Detach yourself from them.

Nobody plays this life with marked cards, so sometimes we win and sometimes we lose.
 Move.
 Do not expect anything in return, do not expect your efforts to be appreciated, your genius to be discovered, your love to be understood.

Stop turning on your emotional television to watch the same program over and over again, the one that shows how much you suffered from a certain loss: that is only poisoning you, nothing else.

Nothing is more dangerous than not accepting love relationships that are broken off, work that is promised but there is no starting date, decisions that are always put off waiting for the “ideal moment.”�

Before a new chapter is begun, the old one has to be finished: tell yourself that what has passed will never come back.
 Remember that there was a time when you could live without that thing or that person — a habit is not a need.
 This may sound so obvious, it may even be difficult, but it is very important.

Closing cycles. Not because of pride, incapacity or arrogance, but simply because that no longer fits your life.

Shut the door, change the record, clean the house, shake off the dust.

Stop being who you were, and change into who you are.

Let's block ads! (Why?)

The 10 Most Important Node.js Articles of 2016

Leave a reply

2016 was an exciting year for Node.js developers. I mean - just take a look at this picture:

Every Industry has adopted Node.js

Looking back through the 6-year-long history of Node.js, we can tell that our favorite framework has finally matured to be used by the greatest enterprises, from all around the world, in basically every industry.

Another great news is that Node.js is the biggest open source platform ever - with 15 million+ downloads/month and more than a billion package downloads/week. Contributions have risen to the top as well since now we have more than 1,100 developers who built Node.js into the platform it is now.

To summarize this year, we collected the 10 most important articles we recommend to read. These include the biggest scandals, events, and improvements surrounding Node.js in 2016.

Let's get started!

Programmers were shocked looking at broken builds and failed installations after Azer Koçulu unpublished more than 250 of his modules from NPM in March 2016 - breaking thousands of modules, including Node and Babel.

Koçulu deleted his code because one of his modules was called Kik - same as the instant messaging app - so the lawyers of Kik claimed brand infringement, and then NPM took the module away from him.

"This situation made me realize that NPM is someone’s private land where corporate is more powerful than the people, and I do open source because Power To The People." - Azer Koçulu

One of Azer's modules was left-pad, which padded out the lefthand-side of strings with zeroes or spaces. Unfortunately, 1000s of modules depended on it..

You can read the rest of this story in The Register's great article, with updates on the outcome of this event.

In October 2016, Facebook & Google launched Yarn, a new package manager for JavaScript.

The reason? There were a couple of fundamental problems with npm for Facebooks’s workflow.

  • At Facebook’s scale npm didn’t quite work well.
  • npm slowed down the company’s continuous integration workflow.
  • Checking all of the modules into a repository was also inefficient.
  • npm is, by design, nondeterministic — yet Facebook’s engineers needed a consistent and reliable system for their DevOps workflow.

Instead of hacking around npm’s limitations, Facebook wrote Yarn from the scratch:

  • Yarn does a better job at caching files locally.
  • Yarn is also able to parallelize some of its operations, which speeds up the install process for new modules.
  • Yarn uses lockfiles and a deterministic install algorithm to create consistent file structures across machines.
  • For security reasons, Yarn does not allow developers who write packages to execute other code that’s needed as part of the install process.

Yarn, which promises to even give developers that don’t work at Facebook’s scale a major performance boost, still uses the npm registry and is essentially a drop-in replacement for the npm client.

You can read the full article with the details on TechCrunch.

New support for Node.js debuggability landed in Node.js master in May.

To use the new debugging tool, you have to

  • nvm install node
  • Run Node with the inspect flag: node --inspect index.js
  • Open the provided URL you got, starting with “chrome-devtools://..”

Read the great tutorial from Paul Irish to get all the features and details right!

Jonathan Zarra, the creator of GoChat for Pokémon GO reached 1 million users in 5 days. Zarra had a hard time paying for the servers (around $4,000 / month) that were necessary to host 1M active users.

He never thought to get this many users. He built this app as an MVP, caring about scalability later. He built it to fail.

Zarra was already talking to VCs to grow and monetize his app. Since he built the app as an MVP, he thought he can care about scalability later.

He was wrong.

Thanks to it's poor design, GoChat was unable to scale to this much users, and went down. A lot of users lost with a lot of money spent.

500,000 users in 5 days on $100/month server

Erik Duindam, the CTO of Unboxd has been designing and building web platforms for hundreds of millions of active users throughout his whole life.

Frustrated by the poor design and sad fate of Zarra's GoChat, Erik decided to build his own solution, GoSnaps: The Instagram/Snapchat for Pokémon GO.

Erik was able to build a scalable MVP with Node.js in 24 hours, which could easily handle 500k unique users.

The whole setup ran on one medium Google Cloud server of $100/month, plus (cheap) Google Cloud Storage for the storage of images - and it was still able to perform exceptionally well.

GoSnap - The Node.js MVP that can Scale

How did he do it? Well, you can read the full story for the technical details:

The aim of the Node Hero tutorial series is to help novice developers to get started with Node.js and deliver software products with it!

Node Hero - Getting started with Node.js

You can find the full table of contents below:

  1. Getting started with Node.js
  2. Using NPM
  3. Understanding async programming
  4. Your first Node.js HTTP server
  5. Node.js database tutorial
  6. Node.js request module tutorial
  7. Node.js project structure tutorial
  8. Node.js authentication using Passport.js
  9. Node.js unit testing tutorial
  10. Debugging Node.js applications
  11. Node.js Security Tutorial
  12. Deploying Node.js application to a PaaS
  13. Monitoring Node.js Applications

This tutorial helps you to use RabbitMQ to coordinate work between work producers and work consumers.

Unlike Redis, RabbitMQ's sole purpose is to provide a reliable and scalable messaging solution with many features that are not present or hard to implement in Redis.

RabbitMQ is a server that runs locally, or in some node on the network. The clients can be work producers, work consumers or both, and they will talk to the server using a protocol named Advanced Messaging Queueing Protocol (AMQP).

You can read the full tutorial here.

James M Snell, IBM Technical Lead for Node.js attended his first TC-39 meeting in late September.

The reason?

One of the newer JavaScript language features defined by TC-39 — namely, Modules — has been causing the Node.js core team a bit of trouble.

James and Bradley Farias (@bradleymeck) have been trying to figure out how to best implement support for ECMAScript Modules (ESM) in Node.js without causing more trouble and confusion than it would be worth.

ECMAScript modules vs. CommonJS

Because of the complexity of the issues involved, sitting down face to face with the members of TC-39 was deemed to be the most productive path forward.

The full article discusses what they found and understood from this conversation.

We at Trace by RisingStack conducted a survey during 2016 Summer to find out how developers use Node.js.

The results show that MongoDB, RabbitMQ, AWS, Jenkins, Docker and Amazon Container Services are the go-to choices for developing, containerizing and shipping Node.js applications.

The results also tell Node developers major pain-point: debugging.

Node.js Survey - How do you identify issues in your app? Using logs.

You can read the full article with the Node.js survey results and graphs here.

The Node Foundation announced at Node.js Interactive North America that it will oversee the Node.js Security Project which was founded by Adam Baldwin and previously managed by ^Lift.

As part of the Node.js Foundation, the Node.js Security Project will provide a unified process for discovering and disclosing security vulnerabilities found in the Node.js module ecosystem. Governance for the project will come from a working group within the foundation.

The Node.js Foundation will take over the following responsibilities from ^Lift:

  • Maintaining an entry point for ecosystem vulnerability disclosure;
  • Maintaining a private communication channel for vulnerabilities to be vetted;
  • Vetting participants in the private security disclosure group;
  • Facilitating ongoing research and testing of security data;
  • Owning and publishing the base dataset of disclosures, and
  • Defining a standard for the data, which tool vendors can build on top of, and security and vendors can add data and value to as well.

You can read the full article discussing every detail on The New Stack.

The Node.js Maturity Checklist gives you a starting point to understand how well Node.js is adopted in your company.

The checklist follows your adoption trough establishing company culture, teaching your employees, setting up your infrastructure, writing code and running the application.

You can find the full Node.js Maturity Checklist here.

The best of Node Weekly in 2016

Leave a reply
A look back at 2016 in the world of Node.js
Read this e-mail on the Web
Node Weekly
December 22, 2016  #168

In this final issue of the year, we look back at the most popular Node links of 2016. We hope you have a happy holiday season and we'll see you in 2017 :-)

Tierney Coren
Using npm as effectively as possible can be difficult. This list of 11 bite-size tricks to help speed up development was very popular this year.


David Gilbertson
David knows Node well, but upon reading through Node’s documentation some more, a variety of interesting techniques jumped out at him.


Smashing Magazine
An incredibly in-depth tutorial, complete with code, diagrams, and insights, into the process behind creating an isomorphic/universal React app using React and Express.


Semaphore   Sponsored
Looking for an easy way to ship your dockerized apps? Try cloud's fastest CI/CD solution with an always up-to-date platform and full-layer caching for Docker images. How fast? Your deployment can take less time than it took you to read this paragraph.

Semaphore

Gergely Nemeth
Node 6.0 was a major release of 2016, but what did that mean for developers?


Igor Soarez
In a 20 minute talk, Igor Soarez looked at how an influx of developers from various cultures has lead to anti-patterns emerging in Node code.


Azat Mardan
Protocol Buffers (protobuf) provide an interesting alternative to JSON. They’re denser and provide data schemas for enforcement of structure.


Realm
Realm is an object database where you simply work with objects as you’re used to and they’re persisted directly.


Gergely Nemeth
Gergely Nemeth covered things like semantic versioning, databases, dependencies, build systems and error handling.


The Register
A big Node story from 2016 that many will want to forget but which had lasting repurcussions.


Jobs

Rest of the Best of 2016

Node Weekly is curated by Peter Cooper and published by Cooperpress.

Want to sponsor an issue? See our media kit.
Want to post a job? E-mail us or use our self-serve system.

Unsubscribe : Change email address : Read this issue on the Web

© Cooperpress Ltd. Office 30, Lincoln Way, Louth, LN11 0LS, UK
Email policy Privacy policy

The best of JavaScript Weekly in 2016

Leave a reply
This year's top JavaScript links — Read this e-mail on the Web
JavaScript Weekly
Issue 315 — December 22, 2016

In this final issue of the year, we look back at the most popular JavaScript news and links of 2016. We close the year with 108,887 subscribers and thank you all for your support! We hope you have a happy holiday season and we'll see you in 2017 with a lot of fun new stuff :-)

Back in January, Eric Elliott started a series of posts digging into common job interview questions. On closures, he noted: “If you can’t answer this question, you’re a junior developer.”
Eric Elliott

A great read from the author of Refactoring where he reimplements an example from the book in ES6, and shows off four refactoring approaches.
Martin Fowler

Jack Franklin also wrote a handy migrating to Webpack 2 guide.
Drew Powers

A look at approaches and best practices to error handling in JavaScript, including how to deal with errors thrown by asynchronous code.
Camilo Reyes

Progress
Kendo UI delivers everything you need to build modern web applications under tight deadlines - from the must-haves Data Grids and DropDowns to Spreadsheet and Scheduler. Choose from 70+ UI components and combine them to create beautiful, responsive apps.
Progress   Sponsor

Still only a couple of months old, Yarn took off as a new way to manage your npm packages.
Facebook Code

A module bundler with super simple code splitting support that aims for extremely efficient packing. It uses Browserify, Babel and Closure Compiler behind the scenes.
Malte Ubl

An attempt to recreate React’s core functionality with as little code as possible and with first-class ES6 support. It has become very popular this year.
Jason Miller

Dr. Axel showed off some tricks enabled by new features in ES6, such as enforcing mandatory function arguments and efficient value swapping.
Dr. Axel Rauschmayer

Detailed results from Sacha Greif’s ‘State of JavaScript’ survey. Over 9,000 of you took part.
Sacha Greif

Raymond Camden offers tips, techniques and tools that can improve your development skills for anyone learning JavaScript.
Telerik Developer Network

Jobs

The Best of the Rest

Functional Programming for JavaScript People tutorial
Chet Corcos

JavaScript Testing: Unit vs Functional vs Integration Tests tutorial
Eric Elliott

ES6 Module Loading: More Complicated Than You Think tutorial
Nicholas C Zakas

Intro to Immutable.js and Functional Programming Concepts tutorial
Sebastián Peyrott

10 Lodash Features You Can Replace with ES6 tutorial
Dan Prince

Build a Fullstack Angular2 + Express.js app with User Management in 10 Minutes 
Get an Angular 2 app up and running in 10 minutes - complete with user registration, authentication, and more.
Stormpath  Sponsor

The Cost of Small Modules opinion
Nolan Lawson

Angular 2 vs React: The Ultimate Dance Off opinion
Eric Elliott

Choosing Vanilla JavaScript in 2016 opinion
Andrew Rabon

The Future of ES6 video
TC39's Jafar Husain gave an engaging talk on where JavaScript is headed now ES6 has become popular.
Jafar Husain

optimize-js: Optimize JS for Faster Initial Loading tools
Nolan Lawson

Create React App: Create React Apps with No Build Configuration tools
Facebook

scientist.js: A Tool for Carefully Refactoring Critical Paths tools
Ziya Sarikaya

Integrated Continuous Testing Tool for JavaScript tools
JavaScript TDD on steroids with instant code coverage right in your editor, now with coverage reports.
Wallaby.js  Sponsor

Viewer.js: JavaScript Image Viewer code
Fengyuan Chen

Draft.js: A Rich Text Editor Framework for React code
Facebook

Clarity: A HTML/CSS/UX Design System and Angular 2 Components code
VMware

AnyPixel.js: To Create Big Interactive Real World Displays code
Google Creative Lab

lightgallery.js: A Full-Featured, Responsive Lightbox Gallery code
Sachin Nchoolur

Curated by Peter Cooper and published by Cooperpress.

Like this? You may also enjoy: FrontEnd Focus : Node Weekly : React Status

Stop getting JavaScript Weekly : Change email address : Read this issue on the Web

© Cooperpress Ltd. Office 30, Lincoln Way, Louth, LN11 0LS, UK

Closing cycles

Leave a reply

Closing cycles

One always has to know when a stage comes to an end. If we insist on staying longer than the necessary time, we lose the happiness and the meaning of the other stages we have to go through.
 Closing cycles, shutting doors, ending chapters — whatever name we give it, what matters is to leave in the past the moments of life that have finished.

You can tell yourself you won’t take another step until you find out why certain things that were so important and so solid in your life have turned into dust, just like that.
 But such an attitude will be awfully stressing for everyone involved: your parents, your husband or wife, your friends, your children, your sister.
 Everyone is finishing chapters, turning over new leaves, getting on with life, and they will all feel bad seeing you paralyzed. .

Things pass, and the best we can do is to let them really go away (however painful it may be!).

Everything in this visible world is a manifestation of the invisible world, of what is going on in our hearts — and getting rid of certain memories also means making some room for other memories to take their place.
 Let things go. Release them. Detach yourself from them.

Nobody plays this life with marked cards, so sometimes we win and sometimes we lose.
 Move.
 Do not expect anything in return, do not expect your efforts to be appreciated, your genius to be discovered, your love to be understood.

Stop turning on your emotional television to watch the same program over and over again, the one that shows how much you suffered from a certain loss: that is only poisoning you, nothing else.

Nothing is more dangerous than not accepting love relationships that are broken off, work that is promised but there is no starting date, decisions that are always put off waiting for the “ideal moment.”�

Before a new chapter is begun, the old one has to be finished: tell yourself that what has passed will never come back.
 Remember that there was a time when you could live without that thing or that person — a habit is not a need.
 This may sound so obvious, it may even be difficult, but it is very important.

Closing cycles. Not because of pride, incapacity or arrogance, but simply because that no longer fits your life.

Shut the door, change the record, clean the house, shake off the dust.

Stop being who you were, and change into who you are.

Let's block ads! (Why?)

The 10 Most Important Node.js Articles of 2016

Leave a reply

2016 was an exciting year for Node.js developers. I mean - just take a look at this picture:

Every Industry has adopted Node.js

Looking back through the 6-year-long history of Node.js, we can tell that our favorite framework has finally matured to be used by the greatest enterprises, from all around the world, in basically every industry.

Another great news is that Node.js is the biggest open source platform ever - with 15 million+ downloads/month and more than a billion package downloads/week. Contributions have risen to the top as well since now we have more than 1,100 developers who built Node.js into the platform it is now.

To summarize this year, we collected the 10 most important articles we recommend to read. These include the biggest scandals, events, and improvements surrounding Node.js in 2016.

Let's get started!

Programmers were shocked looking at broken builds and failed installations after Azer Koçulu unpublished more than 250 of his modules from NPM in March 2016 - breaking thousands of modules, including Node and Babel.

Koçulu deleted his code because one of his modules was called Kik - same as the instant messaging app - so the lawyers of Kik claimed brand infringement, and then NPM took the module away from him.

"This situation made me realize that NPM is someone’s private land where corporate is more powerful than the people, and I do open source because Power To The People." - Azer Koçulu

One of Azer's modules was left-pad, which padded out the lefthand-side of strings with zeroes or spaces. Unfortunately, 1000s of modules depended on it..

You can read the rest of this story in The Register's great article, with updates on the outcome of this event.

In October 2016, Facebook & Google launched Yarn, a new package manager for JavaScript.

The reason? There were a couple of fundamental problems with npm for Facebooks’s workflow.

  • At Facebook’s scale npm didn’t quite work well.
  • npm slowed down the company’s continuous integration workflow.
  • Checking all of the modules into a repository was also inefficient.
  • npm is, by design, nondeterministic — yet Facebook’s engineers needed a consistent and reliable system for their DevOps workflow.

Instead of hacking around npm’s limitations, Facebook wrote Yarn from the scratch:

  • Yarn does a better job at caching files locally.
  • Yarn is also able to parallelize some of its operations, which speeds up the install process for new modules.
  • Yarn uses lockfiles and a deterministic install algorithm to create consistent file structures across machines.
  • For security reasons, Yarn does not allow developers who write packages to execute other code that’s needed as part of the install process.

Yarn, which promises to even give developers that don’t work at Facebook’s scale a major performance boost, still uses the npm registry and is essentially a drop-in replacement for the npm client.

You can read the full article with the details on TechCrunch.

New support for Node.js debuggability landed in Node.js master in May.

To use the new debugging tool, you have to

  • nvm install node
  • Run Node with the inspect flag: node --inspect index.js
  • Open the provided URL you got, starting with “chrome-devtools://..”

Read the great tutorial from Paul Irish to get all the features and details right!

Jonathan Zarra, the creator of GoChat for Pokémon GO reached 1 million users in 5 days. Zarra had a hard time paying for the servers (around $4,000 / month) that were necessary to host 1M active users.

He never thought to get this many users. He built this app as an MVP, caring about scalability later. He built it to fail.

Zarra was already talking to VCs to grow and monetize his app. Since he built the app as an MVP, he thought he can care about scalability later.

He was wrong.

Thanks to it's poor design, GoChat was unable to scale to this much users, and went down. A lot of users lost with a lot of money spent.

500,000 users in 5 days on $100/month server

Erik Duindam, the CTO of Unboxd has been designing and building web platforms for hundreds of millions of active users throughout his whole life.

Frustrated by the poor design and sad fate of Zarra's GoChat, Erik decided to build his own solution, GoSnaps: The Instagram/Snapchat for Pokémon GO.

Erik was able to build a scalable MVP with Node.js in 24 hours, which could easily handle 500k unique users.

The whole setup ran on one medium Google Cloud server of $100/month, plus (cheap) Google Cloud Storage for the storage of images - and it was still able to perform exceptionally well.

GoSnap - The Node.js MVP that can Scale

How did he do it? Well, you can read the full story for the technical details:

The aim of the Node Hero tutorial series is to help novice developers to get started with Node.js and deliver software products with it!

Node Hero - Getting started with Node.js

You can find the full table of contents below:

  1. Getting started with Node.js
  2. Using NPM
  3. Understanding async programming
  4. Your first Node.js HTTP server
  5. Node.js database tutorial
  6. Node.js request module tutorial
  7. Node.js project structure tutorial
  8. Node.js authentication using Passport.js
  9. Node.js unit testing tutorial
  10. Debugging Node.js applications
  11. Node.js Security Tutorial
  12. Deploying Node.js application to a PaaS
  13. Monitoring Node.js Applications

This tutorial helps you to use RabbitMQ to coordinate work between work producers and work consumers.

Unlike Redis, RabbitMQ's sole purpose is to provide a reliable and scalable messaging solution with many features that are not present or hard to implement in Redis.

RabbitMQ is a server that runs locally, or in some node on the network. The clients can be work producers, work consumers or both, and they will talk to the server using a protocol named Advanced Messaging Queueing Protocol (AMQP).

You can read the full tutorial here.

James M Snell, IBM Technical Lead for Node.js attended his first TC-39 meeting in late September.

The reason?

One of the newer JavaScript language features defined by TC-39 — namely, Modules — has been causing the Node.js core team a bit of trouble.

James and Bradley Farias (@bradleymeck) have been trying to figure out how to best implement support for ECMAScript Modules (ESM) in Node.js without causing more trouble and confusion than it would be worth.

ECMAScript modules vs. CommonJS

Because of the complexity of the issues involved, sitting down face to face with the members of TC-39 was deemed to be the most productive path forward.

The full article discusses what they found and understood from this conversation.

We at Trace by RisingStack conducted a survey during 2016 Summer to find out how developers use Node.js.

The results show that MongoDB, RabbitMQ, AWS, Jenkins, Docker and Amazon Container Services are the go-to choices for developing, containerizing and shipping Node.js applications.

The results also tell Node developers major pain-point: debugging.

Node.js Survey - How do you identify issues in your app? Using logs.

You can read the full article with the Node.js survey results and graphs here.

The Node Foundation announced at Node.js Interactive North America that it will oversee the Node.js Security Project which was founded by Adam Baldwin and previously managed by ^Lift.

As part of the Node.js Foundation, the Node.js Security Project will provide a unified process for discovering and disclosing security vulnerabilities found in the Node.js module ecosystem. Governance for the project will come from a working group within the foundation.

The Node.js Foundation will take over the following responsibilities from ^Lift:

  • Maintaining an entry point for ecosystem vulnerability disclosure;
  • Maintaining a private communication channel for vulnerabilities to be vetted;
  • Vetting participants in the private security disclosure group;
  • Facilitating ongoing research and testing of security data;
  • Owning and publishing the base dataset of disclosures, and
  • Defining a standard for the data, which tool vendors can build on top of, and security and vendors can add data and value to as well.

You can read the full article discussing every detail on The New Stack.

The Node.js Maturity Checklist gives you a starting point to understand how well Node.js is adopted in your company.

The checklist follows your adoption trough establishing company culture, teaching your employees, setting up your infrastructure, writing code and running the application.

You can find the full Node.js Maturity Checklist here.

The best of Node Weekly in 2016

Leave a reply
A look back at 2016 in the world of Node.js
Read this e-mail on the Web
Node Weekly
December 22, 2016  #168

In this final issue of the year, we look back at the most popular Node links of 2016. We hope you have a happy holiday season and we'll see you in 2017 :-)

Tierney Coren
Using npm as effectively as possible can be difficult. This list of 11 bite-size tricks to help speed up development was very popular this year.


David Gilbertson
David knows Node well, but upon reading through Node’s documentation some more, a variety of interesting techniques jumped out at him.


Smashing Magazine
An incredibly in-depth tutorial, complete with code, diagrams, and insights, into the process behind creating an isomorphic/universal React app using React and Express.


Semaphore   Sponsored
Looking for an easy way to ship your dockerized apps? Try cloud's fastest CI/CD solution with an always up-to-date platform and full-layer caching for Docker images. How fast? Your deployment can take less time than it took you to read this paragraph.

Semaphore

Gergely Nemeth
Node 6.0 was a major release of 2016, but what did that mean for developers?


Igor Soarez
In a 20 minute talk, Igor Soarez looked at how an influx of developers from various cultures has lead to anti-patterns emerging in Node code.


Azat Mardan
Protocol Buffers (protobuf) provide an interesting alternative to JSON. They’re denser and provide data schemas for enforcement of structure.


Realm
Realm is an object database where you simply work with objects as you’re used to and they’re persisted directly.


Gergely Nemeth
Gergely Nemeth covered things like semantic versioning, databases, dependencies, build systems and error handling.


The Register
A big Node story from 2016 that many will want to forget but which had lasting repurcussions.


Jobs

Rest of the Best of 2016

Node Weekly is curated by Peter Cooper and published by Cooperpress.

Want to sponsor an issue? See our media kit.
Want to post a job? E-mail us or use our self-serve system.

Unsubscribe : Change email address : Read this issue on the Web

© Cooperpress Ltd. Office 30, Lincoln Way, Louth, LN11 0LS, UK
Email policy Privacy policy

The best of JavaScript Weekly in 2016

Leave a reply
This year's top JavaScript links — Read this e-mail on the Web
JavaScript Weekly
Issue 315 — December 22, 2016

In this final issue of the year, we look back at the most popular JavaScript news and links of 2016. We close the year with 108,887 subscribers and thank you all for your support! We hope you have a happy holiday season and we'll see you in 2017 with a lot of fun new stuff :-)

Back in January, Eric Elliott started a series of posts digging into common job interview questions. On closures, he noted: “If you can’t answer this question, you’re a junior developer.”
Eric Elliott

A great read from the author of Refactoring where he reimplements an example from the book in ES6, and shows off four refactoring approaches.
Martin Fowler

Jack Franklin also wrote a handy migrating to Webpack 2 guide.
Drew Powers

A look at approaches and best practices to error handling in JavaScript, including how to deal with errors thrown by asynchronous code.
Camilo Reyes

Progress
Kendo UI delivers everything you need to build modern web applications under tight deadlines - from the must-haves Data Grids and DropDowns to Spreadsheet and Scheduler. Choose from 70+ UI components and combine them to create beautiful, responsive apps.
Progress   Sponsor

Still only a couple of months old, Yarn took off as a new way to manage your npm packages.
Facebook Code

A module bundler with super simple code splitting support that aims for extremely efficient packing. It uses Browserify, Babel and Closure Compiler behind the scenes.
Malte Ubl

An attempt to recreate React’s core functionality with as little code as possible and with first-class ES6 support. It has become very popular this year.
Jason Miller

Dr. Axel showed off some tricks enabled by new features in ES6, such as enforcing mandatory function arguments and efficient value swapping.
Dr. Axel Rauschmayer

Detailed results from Sacha Greif’s ‘State of JavaScript’ survey. Over 9,000 of you took part.
Sacha Greif

Raymond Camden offers tips, techniques and tools that can improve your development skills for anyone learning JavaScript.
Telerik Developer Network

Jobs

The Best of the Rest

Functional Programming for JavaScript People tutorial
Chet Corcos

JavaScript Testing: Unit vs Functional vs Integration Tests tutorial
Eric Elliott

ES6 Module Loading: More Complicated Than You Think tutorial
Nicholas C Zakas

Intro to Immutable.js and Functional Programming Concepts tutorial
Sebastián Peyrott

10 Lodash Features You Can Replace with ES6 tutorial
Dan Prince

Build a Fullstack Angular2 + Express.js app with User Management in 10 Minutes 
Get an Angular 2 app up and running in 10 minutes - complete with user registration, authentication, and more.
Stormpath  Sponsor

The Cost of Small Modules opinion
Nolan Lawson

Angular 2 vs React: The Ultimate Dance Off opinion
Eric Elliott

Choosing Vanilla JavaScript in 2016 opinion
Andrew Rabon

The Future of ES6 video
TC39's Jafar Husain gave an engaging talk on where JavaScript is headed now ES6 has become popular.
Jafar Husain

optimize-js: Optimize JS for Faster Initial Loading tools
Nolan Lawson

Create React App: Create React Apps with No Build Configuration tools
Facebook

scientist.js: A Tool for Carefully Refactoring Critical Paths tools
Ziya Sarikaya

Integrated Continuous Testing Tool for JavaScript tools
JavaScript TDD on steroids with instant code coverage right in your editor, now with coverage reports.
Wallaby.js  Sponsor

Viewer.js: JavaScript Image Viewer code
Fengyuan Chen

Draft.js: A Rich Text Editor Framework for React code
Facebook

Clarity: A HTML/CSS/UX Design System and Angular 2 Components code
VMware

AnyPixel.js: To Create Big Interactive Real World Displays code
Google Creative Lab

lightgallery.js: A Full-Featured, Responsive Lightbox Gallery code
Sachin Nchoolur

Curated by Peter Cooper and published by Cooperpress.

Like this? You may also enjoy: FrontEnd Focus : Node Weekly : React Status

Stop getting JavaScript Weekly : Change email address : Read this issue on the Web

© Cooperpress Ltd. Office 30, Lincoln Way, Louth, LN11 0LS, UK