For those of us in the open source, trendy, node, rails, iOS, Android lands it’s easy to forget that there is a whole developer ecosystem out there centred around C#, .Net, Azure and much more. We, and I include myself in this group, have forgotten about the MS ecosystem. Maybe we were burnt by VB or by Windows Vista being... Whatever it was, we moved away to other, newer tools and didn’t really look back. But I think now, 2016, is the time to take a second look. In case you missed it, there’s a , and he appears to have his head screwed on properly. In just a few years he and his team has lead the charge on some super cool stuff. Let’s take a look at these. new guy in charge C# C# is like Java, but fixed. It’s got similar syntax but has got so much more. It’s a superset of C, with classes, inheritance, interfaces (protocols) and much more. If you’re thinking that’s a bit dull now, and you’re a functional programmer now, then F# is also just as cool. If you’re somewhere in between, the framework will do that for you. It’s also not new either, so it’s pretty stable and theres no week long migration to the next version. (👀 Swift) LINQ .Net Core is a cross platform, open source, free, cut down version of .Net for on Linux, Mac, Windows and even IoT embedded devices. It’s got all the fun of C# and a sensible collection of foundation classes for building whatever you’re building. Oh, and it’s super fast. Not like Node or Ruby fast, actual fast. After talking to a local company, they were able to replace a node.js server doing 800 requests per second with a .Net server doing 20,000+ requests per second. Nice. .Net Core VS Code and VS for Mac In case you haven’t seen it, Microsoft released and it’s pretty darn cool. Once again, open source, cross platform and free. You can think of it like Atom or Sublime, and like those two, they have many extensions for things like Git or other languages. And then we got a preview version of in the last couple of weeks too. The awesome IDE on Windows is starting to make it’s way over to us now which is pretty neat. It’ll only get better, too. VS Code Visual Studio for Mac Azure Machine Learning Azure, which is pretty much Microsoft’s , now has a . All tied in with other services, it’d be a trivial add on to your application. A lot of AI algorithms and bayesian math is implemented for you and wizards to help you choose the right one for your application. AWS bunch of cool AI tools Bot Framework The same goes for the . You can create interfaces to Skype, Facebook, Slack and More. It even can run serverless, where you pay for only the resources you consume. MS Bot Framework Hololens The hololens is freakin’ amazing. Read my thoughts . Also, if your app works on Windows 10 Desktop or Phone, it’ll probably on Hololens_._ here just work Microsoft Surface Studio This is one for the designers, the Surface Studio is basically a what happens if you turn a drafting table into a computer. It’s something that I think will actually work super well for designers. has to offer. There’s so much more to look at. Universal Windows Apps for write once(ish) run everywhere, Microsoft Surface Hub for meetings, Azure DevTest Labs, Xamarin, Azure IoT Hub, Power BI and much more! These are just some of the cool things Microsoft it’s time to take a second look. No solution is perfect, and to suggest tech from “the other side” won’t be the best solution is pure stubbornness and arrogance. Take a second look. Have an open mind. They’ve come a , and for your future applications and endeavors, it could be the . In conclusion, long way right way , go to a .Net meetup, or check our your local conference. Heck, go to ! So go do it Ignite Build Thanks for reading. Don’t forget to hit that heart below to give me the warm fuzzies. I’m also on Twitter if you wanna chat — I’d love to see you there. @samjarman is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

BUNCH

Facebook

Microsoft

Slack

Super

Twitter

Developers, it’s time to take a second look at Microsoft

Before ES5, JavaScripters were living in a Callback Hell. Debugging was a crazy console.log-ing inside thousand of callback functions. Then Promises came to rescue JavaScripters. The Magic of Promises turned that Hell into a flat structure, and it was the light at the end of the tunnel. Async Await was the incarnation of the Promise. ES7. 8 must know Examples : AsyncFunction Object Promise function Async function Await Sequentially Await Parallelly Await Nest Await Dynamically Error Handle Note e — This story only focuses on Asynchronies issue. — To Nodejs developer, to run ES7 please read: BBB, Babel Burger Boilerplat Chronological Picture 1- Constructor of async: asyncFunction The AsyncFunction constructor creates a new Async function object. In JavaScript every Async function is actually a AsyncFunction object. From : Mozilla console.log(async function () {}); Who has known that AsyncFunction and Promise siblings? If no you can are not permitted to skip, because this is the reason why await is supported by ES6's Promise functions and how the characteristic of Promise is applied by Async await, such as and : Resolving Parallel Error Handling function(){...return new (function(resolve, reject) {...})...} Promise 2- Constructing Promise function Why are we talking about Promise functions here? Because people may have missed that the foundation of Async await are promises, every Async function we create and every thing that we Await will naturally become a promise. Example (Thanks for ’s suggestion): Jyotman Sing (async function() { var sleep = function(para) {return new Promise(function(resolve, reject) {setTimeout(function() {resolve(para * para)}, 1000)})} var result = await sleep(2)// result is 4 })(); 3- Constructing Async function The declaration defines an , which returns a object (also a promise). When the async function returns a value, the promise will be resolved with the returned value. When the async function throws an exception or some value, the promise will be rejected with the thrown value ( ). **async function** async function [AsyncFunction](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncFunction "The AsyncFunction constructor creates a new async function object. In JavaScript every async function is actually a AsyncFunction object.") Mozilla Example: async function asyncSleep (para){return await sleep(para)} var result = await asyncSleep(2)//result is 4 asyncSleep(3).then(function(result2){//result2 is 9}) 4- Await Sequentially Example: var result1 = await sleep(2);var result2 = await sleep(result1);var result3 = await sleep(result2); //result1 is 4//result2 is 16//result3 is 256 5- Await Parallelly Example: var results = await Promise.all([sleep(1), sleep(2)]);//results is [1,4] 6- Nest Example: for(var i =0 ; i<3; i++){var result = await sleep(i); for(var j =0 ; j<result; j++){  
    console.log('   i:'+i+', j:'+j+': ', await sleep(j));  
} } // i:1, j:0:  0// i:2, j:0:  0// i:2, j:1:  1// i:2, j:2:  4// i:2, j:3:  9 7- Dynamic Async functions Fellow JavaScripters, it’s time to admit it: we have a problem with promises ( ). Nolan Lawson I really agree with quote_._ Dynamical Promise Array is demanded when dealing with unknown process, dynamical problem. To the issue, my instinct was to push all the Promise functions into an Array, then await each of them sequentially. But it was proved incorrect when I discovered that the Promise functions executed while they were being declared. My conclusion is, don’t trust human instinct when solving problems with Promises. Nolan Lawson ’s The walk-around is to store parameters and promises separately (map object is used here) Example: var sleep = function(para1,para2) {var _para1 = para1, _para2 = para2 || para1 ;return new Promise(function(resolve, reject) {setTimeout(function() {resolve(_para1 * _para2)}, 1000)})} var proMap = new Map();proMap.set([1], sleep);proMap.set([2, 3], sleep);proMap.set([3], sleep); for (var [para, fun] of proMap.entries()) {var result = await fun.apply(this, para);console.log(para, result)} //[ 1 ] 1//[ 2, 3 ] 6//[ 3 ] 9 8- Error handle within an function Errors are swallowed “silently” async – just like inside normal Promises ( Nicolas Bevacqua ). Error handling in both and were born from the same mother, they both needed try/catch, so that errors are captured and handled in awaited promises from within the async function. Async Promises Example: var errorSleep = function(para) {return new Promise(function(resolve, reject) {setTimeout(function() {reject(' ErrorSleep')}, 1000)})} var result1 = await sleep(1);var result2 = await errorSleep(4);var result3 = await sleep(1); _try {_ console.log('result1: ', result1)  
console.log('result2: ', result2)  
console.log('result3: ', result3) console.log('err: ', err)console.log('result1: ', result1)console.log('result2: ', result2)console.log('result3: ', result3) _} catch (err) {_ } //err:   ErrorSleep//result1:  1//result2:  undefined//result3:  undefined : Summary Good, async/await is a great syntactic improvement for both nodejs and browser programer. Comparing to Promises, it is a shortcut to reach the same destination. It helps developer to implement functional programming in JavaScript, and increases the code readability, making JavaScript more enjoyable. Bad, as mentioned in part 7 and 8, Promise has problem in generating instance dynamically and resolving the instance, also await should have given Javascripter a louder shout when an accident exception is found. Like this story? It is helpful to others? It helps me know if you’d like to see write more about his topic and helps people see the story, . when tap the heart below Reference: Source: https://medium.com/@peterchang_82818/javascript-es7-async-await-bible-tutorial-example-32294f6133ab#.m33vwg1yx Mozilla: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncFunction Nicolás Bevacqua https://ponyfoo.com/articles/understanding-javascript-async-await Nolan Lawson https://pouchdb.com/2015/05/18/we-have-a-problem-with-promises.html

Mozilla

Asycn Await BIBLE: Sequential, Parallel, Nest, Dynamic and Error Handle in Javascript

If you’re an entrepreneur — or an aspiring one — you may think blogging is the last thing you’ve got time for. And you might be right. After all, there’s no immediate business value to be drawn from writing regularly, and it takes away the time you might spend developing your product or speaking to investors. But only by running your own business do you learn that it’s precisely those long-term investments — which don’t always show immediate payoffs — that make all the difference. Blogging is one of them. Even though its value is so hard to quantify, many of the most successful entrepreneurs are dedicated to the practice and see it as something crucial to their roles. Here are five reasons why blogging is so important for entrepreneurs. Blogging nurtures ideas Writing doesn’t just communicate ideas; it generates them. — Paul Graham Blogging daily forces you to be on the lookout for new ways of thinking — to react to others’ ideas and sort through your own. It helps you develop a state of mind that makes you more observant and contemplative. After all, writing every day requires you to develop new (and hopefully interesting) concepts and points of view on a regular basis. Blogging will help you acquire that skill, which you can then apply to other creative areas in your life and business. Blogging helps you shape your vision When you have to write your ideas out in complete sentences, it forces a deeper clarity of thinking. — Jeff Bezos When they first pop into our heads, most of our ideas are fragile and vague. Blogging about them requires you to think more deeply, fleshing out your ideas and understanding them better. Not does that help you clarify your thinking, it helps you communicate your ideas to others. You can’t succeed without a clear, concise vision. Can you imagine an entrepreneur without an elevator pitch? It’s that vision that guides you towards making the right product decisions, finding creative ways to get users on board, attracting talented staff, and getting investors to believe in your mission. Blogging is one of the best ways to distill this vision. Blogging helps you build an audience We’re trying to build an audience through our writings; we’re not just trying to have customers. — David Heinemeier Hansson Kevin Kelly’s is one of the most influential blogs in the startup world. All you need for a sustainable business, as Kelly makes clear at the outset, is a small audience of true fans. What better way to attract them than by sharing ideas that compel them to follow you? Basecamp, Product Hunt, Treehouse, Mattermark, and Groupon — just to name a few — were all started in recent years by founders who had built up an audience long before they ever had a product. In fact, it was those very audiences that helped develop and distribute those products, turning the ventures into successful businesses. 1,000 true fans Blogging makes you an industry expert When I hit publish, I get a rush. Every time. Just like the first time. It is incredibly powerful. — Fred Wilson Well-written, relevant posts will help you position yourself as an industry expert and get your name out there among people in your field. The more you know about the things you’re writing about, the more likely potential users and partners will trust you to offer them a great product or service. In fact, educating your readers is actually a great form of marketing all by itself. Kathy Sierra, co-creator of Head First, many years ago: “The most important skill for marketers today is . . . teaching. While in the past, those who outspent (on ads and big promotions) would often win, that’s becoming less and less true today for a lot of things.” aptly described it Blogging teaches you about entrepreneurship Writing is more a medium of self-discipline than a way to communicate information. — Andy Grove , Intel While blogs are generally considered external communication platforms, the actual practice of blogging is much more introspective. It can teach you to focus on small gains, value simplicity, take consistent, deliberate actions — all useful habits for entrepreneurs. There are less obvious connections between writing and business activities, too. Acquiring readers, for instance, isn’t all that different from acquiring customers. But require making connections and building relationships over time. Perhaps the best thing about blogging is that it’s accessible to everyone. You don’t need a publisher, you don’t need a degree, you don’t need a product. Hell, you don’t even need to be all that good a writer. What you do need is something to say. And entrepreneurs, pretty much by default, all have plenty of that.

Basecamp

5 reasons every entrepreneur should start blogging

It’s right at the end of 2016 and I’ve leapt into a new startup as the only engineer. My first big decision is what technology stack to build our product with. I’ve picked nodejs and here is why. It’s what I know best This is the main reason, and one that’s almost always the best one when starting something from scratch. There’s lots of really interesting languages and frameworks out there. I’m really interested in functional programming and loved my time working in Ruby so Elixir and Clojure were two things that sprung to mind. I’ve reached professional proficiency in a few languages now, so I don’t think it would take me long to get to grips with either of those. It’s not that simple though: all languages come with their own idioms, frameworks, package mangers, devtools and deployment issues. For Clojure, sure I can code LISP, but I know nothing about running the JVM in production. Turns out I’m not Rich Hickey. Sticking to what I know means that I don’t need to lose any precious time learning new tricks or troubleshooting problems of my own making due to not understanding the stack in depth. I cut out a big chunk of risk too. I know what I’m getting myself into. When doing an early stage startup there will be so much that you can’t know — it makes sense to cling to what little you do. You can build things quickly with it While not quite as productive as Ruby on Rails, you can still move very quickly. There is a module for pretty much anything you can imagine for nodejs thanks to the amazing ecosystem. I’ll save time by using other people’s modules. Not all of them are very good but I can tolerate the odd shabby implementation for now. I will write my own later if and when I have problems that aren’t ” or . npm “Having no product “Having no customers” It’s not cool anymore Nodejs is now mature and battle tested and is being used by a great many of big technology companies such as and . Even Microsoft are keen to . This means that money is being spent on keeping it stable and making it better. I can be confident that it’s not going to be abandoned or neglected any time soon. Netflix Paypal join the party Lingua franca Back in 2007, Jeff Atwood wrote another of his . In it he coined a phrase: influential blog posts JavaScript is the of the web. Ignore it at your peril. lingua franca Since 2007 this has only got more true. The way I like to think of it is this: Javascript is the English of programming languages. It might not be the best, it’s certainly loaded with quirks but it’s easy to pick up and it gets the job done. More pertinently it’s absolutely everywhere now and there’s nothing anyone can do about it. Javascript comes to the server. The one certainty of making a web application is there will be javascript in it somewhere, if only as the output of a transpiler. Things that can’t be avoided should be embraced. If you are stuck with something, you might as well learn to get the best out of it. It helps me keep things simple I want to keep my life as simple as it can be. By picking nodejs I can use one language right the way through all of my stack rather than having something for the client and something for the server. We stick with the classic web triumvirate of HTML, CSS and javascript. I can hire engineers of all stripes so long as they know a bit of javascript and almost all web developers do. There’s other nice things, like being able to share code across the browser and the server. Something that makes reasonably straightforward. reactjs It will last me a long time Nodejs is plenty fast enough to scale pretty nicely, and when I have out grown it, I will be a long way from where I am now. This is a problem I would dearly love to have. When that day nears, it won’t be the end of the line for nodejs. I see it being a part of my system in perpetuity. As I said, right now I want to keep things simple. This goes for my architecture too so my app will be a monolith for now. One codebase, one deployment, everything in one place. Microservices are a great solution for problems involving scale and complexity; For productivity, not so much. Time spent messing with service discovery, load balancing and the rest is time I’d rather be using to create product. The monolith. It’s not very fashionable, but it is very simple. One day though, my monolith will start to creak, some bits will be too slow and the whole thing will become unwieldy due to it’s sheer size. I’ve been at startups that got to this point with their Rails application. Attempts to extract functionality and encapsulate it out of process or fully distributed were successful, but brought substantial drawbacks. Ruby is single threaded and blocking. When a Rails app makes a call on the network, the whole thread waits for the response before doing anything else. The more services you add, the longer you wait. This meant that in the transition period, things got pretty slow, and the further into the transition we went the worse it got. It also resulted in a near extinction of Ruby in the codebase. While Ruby and Rails enabled the team to move quickly in the early stages, later on Ruby didn’t seem the best choice for a distributed system. All the team’s Ruby knowledge was wasted post transition and it made the Rubyists sad. With a nodejs system, things are a bit easier. While it is single threaded, it’s also asynchronous and non blocking. This means that while we wait for the network to do it’s thing other requests will be serviced. Adding distributed components does not destroy performance. Better still, javascript will never completely go away. As more services are extracted, the nodejs tier will gradually shrink into a anaemic web tier. It will have fewer responsibilities than in the monolith days but will still have a vital role aggregating calls to the services, rendering html managing sessions and other web stuff. There will be plenty of server side javascript too. While many of the services may well end up being written in a new language (maybe I will get to play with Elixir and Clojure after all!), the institutional javascript knowledge will not be completely wasted. It take a a village of services to build a system. All safely behind a thin wall of nodejs. In summary It’s what I know best Supported by the wider industry It’s really productive Everyone knows javascript Sharing code across client and server is nice There’s no avoiding it anyway It’s good enough for now, but leaves a pathway to different things I guess we will see over the coming years if I live to regret my decision. In the mean time, I’m also hiring the first member of my engineering team. So if you fancy hacking on nodejs, drop me a line: dom@terriertech.io

Discovery

Netflix

Why I picked nodejs for my startup

Process, accountability, chaos and the illusions of progress. This lament was recently fast-pitched to me by a CEO client. I tried to explain why process is important, and that lack of process is most often replaced by semi-controlled chaos, the illusion of progress, health crashes, and risk profiles that tend to snowball into future time, only to melt during the most inconvenient season in a company’s life. “We don’t need process, we need progress. We’re a small startup. Everything is slow, there are too many gates.” I’m extremely passionate about process. I got this way by taking too many risks, working too much, failing too much, jeopardizing my health for my career, but above all by developing an incredible respect and empathy for the expert builder. Process is about people; it’s about how we want to live our lives. By extension, if we mandate a process for others, then we are showing them how we think it best for them to live their lives. Ethics Process is about . Who am I? What is my worth? What am I willing to compromise for my employer? What part of my life does my employer own? Do they have a right to ruin my health? Do they own my confidence? Do they own my weekends? Do I owe them my evenings as well? ethics As software builders, our codebases own us. Because our codebases and various infrastructure are running every second of every day, this presents many unique life challenges for builders. The company owns our codebase. Thus, by extension the company owns our life. The company’s internal processes then, are a declaration of ethics about employee productivity, health and well-being. The inevitability of success If a company is successful, people will need to work at an uncomfortable pace for extended periods of time, sometimes measured in years. People who work too much get tired. Tired people are less efficient. Tired people are more irritable. Tired people get sick easily. Tired people will operate according to a greater percentage of sub-optimal or cloudy assumptions. One of the more common things I see is burnout. I’d say that 80+% of the people I’ve known in the startup game (myself included) have worked themselves to complete burnout at some point in their careers. By burnout I mean that after they slow down, exit, or a company folds, they cannot work in a normal productive capacity for 12+ months. Some even wonder if ‘burnout’ should be eligible for (DMS). Perhaps it’s a rite of passage, but overwork by any of its names is serious, life altering, existential stuff. addition to the Diagnostic and Statistical Manual of Mental Disorders — a system of reasonable constraints that dictate organizational workflow, scheduling, cadence, batch size (i.e. the amount of work-in-process at any given moment), automation, and failure mitigation and resolution. These considerations are at the core of things like Lean, Scrum, XP, Agile, Kanban. —inspired by the people who have the most to lose from an institutionalized lack of process or semi-productive chaos. In light of real success and the pace that comes with it, the only thing that can ensure an ethical environment for employees is process Any process needs to be co-signed from the top of an organization, and inspired by the bottom of an organization The fallacy of working harder vs. expert efficiencies Expert builders are said to be up to 10X as productive as junior employees. This means that what takes a junior person 10 years to build, an expert will build that in a year. This idea should be lost on anyone. The 10X estimate may even be 10X low when considering that the expert will make entirely different decisions that contribute to long-term stability; like building a house on sand instead of concrete. never But why are experts so efficient? They remove waste from ideas/systems in their mind, before speaking, before paper, before design, before code. Their brains are already trained to operate within an enforced system of skill-specific constraints, i.e. these people are highly structured, they follow internal processes. This internal system of constraints will produce cleaner, more realistic ideas that are already fact-checked against a career of wars against complexity. This is why experts need process. Lack of process destroys efficiency by allowing them to become the organizational filter for whimsical direction and decision making. *This is not to say that only builders are experts at things, and does not consider creativity. In software systems, builders are almost always the finite resource. Ideas and creativity are quite limitless, while time to code will always be limited by expert throughput. Accountability of upstream resources As alluded to above, one of the most redeeming qualities of any well-designed process is that upstream resources are bound and constrained by downstream requirements. In essence, the experts, or the most efficient minds in the system, expect inbound requests to match their level of distillation and critical thinking, and will often set up queueing and requirements for the upstream resources. This is done to help upstream languages speak a closer language to the expert. This allows the experts to keep efficiency extremely high, and will also create a ‘pull’ system, where someone on the team can pull a task at which time it’s already concepted, partially designed, distilled and vetted, i.e. ready. This starts to create accountability for the upstream resources. The above scenario could be visualized with the concept-design-build pipelines we often seen in the software industry. The cost of interruptions, multitasking and context switching Another benefit of good process is the potential for a in interruptions, multitasking, and context switching for employees who require long periods of focus. More people are starting to report on the costs of interruptions at work like , and . drastic reduction here here here Simply put, employees want to make their managers and executives happy. Technical employees are often unofficially tasked with helping people learn and understand the myriad possibilities. If each day a technical employee fields four requests, that means an acute interruption every two hours. It has been suggested that after an interruption, it can take an average of ~25 minutes to regain focus. If we allow for four interruptions per day, that sets the potential for 100 minutes (almost two hours) of wasted time. This is catastrophic for efficiency and productivity. With many of our contemporary offices having open and social floor plans, only four interruptions per day might be optimistic, it could be much worse. Imagine then, these distracted employees will need to work all night, every night, in order to find the quiet and predictable environment in which to complete their work. Authority, choice, and outcomes Process must be a top-down initiative. How many execs who talk Agile or Lean take the time read a well-known book about it? Or better yet how many hire a agile/lean coach who has been actively building software the past five years, instead of just coaching? How many executives simply lack the discipline and foresight to accommodate real process? real The executives that promote zero-process, or fluid-process, or when-I-say-something-you-need-to-seem-like-you’re-immediately-responding-process, they will get the output associated with that type of environment. This progress will likely be short-lived and illusory. Furthermore, these executives will naturally attract people that do not yet understand how destructive long-term process chaos will be for those most affected, i.e. inexperienced people who are much less efficient. It reminds me of the famous eastern quote: “So long as the bosses pretend to pay us, we will pretend to work.” Except in our version: “So long as the bosses pretend to know what they’re talking about, we will pretend we don’t need process to be successful in business and life.” Does expecting process mean that we are entitled or lazy? Absolutely not. While we have it pretty great in the software industry, there are no statutes or norms in the industry to protect people from brutal workloads and long hours. Only our elder statesman have the experience to know better. That’s largely where our . It turns out these processes are also very good for the customer and product. contemporary processes came from Why can’t we just ‘freestyle’ it? Well, you can and many people do. However, without a system of constraints on work-in-process, a team will run into the age old conditions of compounding risk profiles, feature scope creep, unpredictable ROI on people and code, and more. Progress and risk This is the ultimate question. We are often under dire pressure to make hasty decisions that benefit us today, while incurring much debt far into the future. The debt from these pressures is impossible to quantify, but will come in code, morale, health, relationships and all measure of nuanced organizational cancer. Is it progress today if it costs us double next week? Process likens to the ‘tortoise and hare’ analogy. It’s a good one. However, with our contemporary tools and methodologies, the tortoise is getting quite a bit slimmer and faster. As such, it’s imperative that executives acknowledge the entire field of play before advocating for less process. In the end, some teams can and have been successful without established process. Absolutely. I’m just not willing to work with them, because my life, career and craft are about much more than the mythical startup hustle.

Building ethical environments for people.

The Graph

Amazon

Apple

fees

Google

Instagram

JUMPER

ORANGE

Techcrunch

Transit

Uber

Yellow

Read My Stories

⭐️ On the Exponential View

In this blog I will show you how to pick up an existing codebase example and curtail it into your own, beautiful single page website built using Node.js and . This is a single-page website built on a light Node.js server with a front end by at . I’ll be using (an API-first CMS that makes managing and building websites and applications faster and more intuitive) to install, edit content, deploy and make content updates moving forward from a . Cosmic JS Stellar Cosmic JS App @ajlkn HTML5 UP Cosmic JS web-based CMS If you haven’t already, get started by for . Helpful resources are provided below to streamline your development operations. Signing Up Cosmic JS Stellar App Page Stellar App Demo Stellar App Codebase on GitHub 1. Create a New Bucket Your bucket’s name is the name of your website, project, client or web application that you are building. I named mine “Node.js Single Page Website” to remain concise for our example blog. 2. Install the Node.js Single Page “Stellar” App Once you’ve signed up and named your bucket, you’ll be prompted to start from scratch or “see some apps”. For this blog I simply clicked the right button to “see some apps” so that I could begin the installation process for the Node.js Single Page Stellar App. App Installation Options gives you the ability to filter between programming languages such as and more. Simply click “Install” underneath the Stellar icon to get started, or visit the . Cosmic JS Node.js, PHP, React, AngularJS Cosmic JS Apps Page 3. Deploy to Web I clicked “Deploy to Web”. I can then start editing my Objects while my web application is deploying. You will receive an email confirming the deployment of your web application. If you encounter any issues during deployment, you may be routed to the . Cosmic JS Troubleshooting Page Confirm Deploy Location and Branch Deploy Branch Confirmation Modal I’m drawing from a repo, my branch is clarified and I have a deployed location that matches my slug / bucket name that I made in Step 1. Deploy, Deploy Away A little reassurance that you’ll soon be up, alive and well on the web. :) 4. Edit Global Objects, Object Types and Objects Editing is a dream come true in the Cosmic JS Dashboard. To read more about how Cosmic JS was built with editing content in mind, read Building With the Content Editor in Mind. App Deployment Confirmation It’s as easy as sign up, create new bucket, install web application, edit content and deploy! I get my confirmation email to access my web application and also see my options for bucket upgrades like custom domains, one-click SSL, webhooks and localization. is an that makes it easy to manage applications and content. If you have questions about the Cosmic JS API, please reach out to the founders on or . Cosmic JS API-first cloud-based content management platform Twitter Slack Carson Gibbons is the Co-Founder & CMO of , an API-first Cloud-based that decouples content from code, allowing devs to build slick apps and websites in any programming language they want. Cosmic JS Content Management Platform

Stellar

Follow me on Twitter

Build a Node.js Single Page Website in 4 Steps

“Everything that can be automated will be automated” — Zuboff’s Law Automating a boost to my GPA In Ben-Gurion University’s Computer Science program there are points you get by enrolling in one of the optional courses. Some courses are considered easier than others, and one is considered by far the easiest — The History of Math. Rather than solving equations all you have to do is learn a little bit of history. Piece of cake, an easy way to boost your GPA. Problem is since this course is so easy, it’s also the most popular. When the bell rings to mark the beginning of the course registration period, hundreds of students are furiously hitting the keyboards to log in to the system and grab the easiest courses they can get, the History of Math as the holy grail. Similar to HFT trading firms, those who really go the length find a University computer that is the closest to the university servers to have their registration request arrive before anyone else’s. Surely enough I wasn’t lucky to get into History of Math. But there was hope. The following 2 weeks are what is called “Change Period” where students can change their courses if they find availability or need to cancel their spot. During that period when ever you would have time, you would log in and check if someone gave up their spot for History of Math or what ever course you wanted. It occurred to me that I could write a script that will send the same network traffic my browser sends when I click the mouse and tap the keyboard. Some hours later, . the fix was in The fix was in. As I would go about my day, the program would continuously poll the course registration system every . second Not long after I received an email that my program successfully registered me to History of Math! Success! After I pulled the same trick for 6(!) of my friends the word got out. When a Teaching Assistant emailed me and asked me for the program, I figured the jig was up. Turns out he just wanted to use it for his wife. The following year my friends, who were still students, got an email from the administration that starting that year online course registration would require entering Captcha codes. So glad I could be of help to the I.T department of Ben-Gurion University. Experiencing major inefficiency A year later I was working as a software engineer. I worked on many projects — mobile apps, websites, mostly consumer software. The process was that once the UI design was ready, I would get mockups of the design and the assets that compose it. Then would begin the process of coding the UI based on the mockups, followed by a tedious back and forth between myself and the designer until either the designer would be happy or the time to deliver was up, whichever came first. http://www.projectcartoon.com/ There was nothing creative about that process. The design was already decided, all I had to do is to push pixels left and right until they match the static photo I was given. Not exactly the fun part of programming. I love programming. I love solving problems in creative ways. I’m not really into reading a set of instructions in the form of pixels and following them. A Glimpse Into The Future It is now 2017 and the process of designers handing off mockups and engineers grunting and pushing pixels is exactly the same as it was then and the same as it was 20 years ago. Now I want you to imagine this: It is now 2020. Driverless cars are roaming the streets. The “No Idling” signs you used to see on road trips when you stopped for gas are gone. Trucks no longer stop at these pit stops. The trucks are fully autonomic and there are no drivers that need to rest. Photo credit At that point in time, writing code based on mockups should be a thing of the past as well. There will still be plenty of front-end work to be done by human software engineers, but it will be creative work. All the mundane work will be done by automated software. Everyone will be happy. Designers would get to see their pixel-perfect design come to life in a split of a second, and engineers would be working on things that machines can never do — be creative. probably Photo credit In the future I envision we won’t be seeing front-end engineers holding signs demanding their jobs back. The Future Has Begun In fact, the I’ve co-founded along with and is doing that. startup Avishay Cohen Michal Cohen In the past 6 months we have that empower designers to express their designs better. We turned static design into dynamic . As a side-effect of expressing designs with our tools, we get to control how the output looks like. Being able to control the output means we can use that as input to our Automation machine that spits out real code. released tools design Take for example landing pages — usually simple enough that they don’t take too long for a front-end engineer to build them. But what if they don’t have to? What if designers can publish landing pages straight from their working tool— Sketch; and engineers can work on the actual products? With you can already do that. We enable designers to publish completely functional websites they designed themselves rather than templated or ready-made websites; without needing any developers. Launchpad _The latest from Anima App (@AnimaApp). Empowering designers. New York/Tel Aviv_twitter.com Wall of Love from Anima App on Twitter The journey towards full design to production-ready-code automation is ahead. We are laying the foundation to what will become a hoodie-less frontend engineer. Photo credit Thank you for reading. If you want to join our journey visit us at: https://www.animaapp.com

Stacks

Zones

Automation will end Front-end Development

Following the release of , I wanted to revisit the performance differences between Diesel and rust-postgres to see if things had changed significantly Diesel 0.9.0 since I last measured both in 0.1.0. TL;DR: Diesel consistently outperforms rust-postgres by 25–30% in idiomatic code. It is also more concise and catches errors at compile time to help you write working code faster. You can find the full benchmarking code . The rust-postgres benchmark could be further optimized to find about a 10% performance increase. Doing this, however, results in code that is more brittle and harder to understand. here If you’re looking for something to do this holiday season, and you haven’t tried Diesel yet, check out our . The rest of this article is going to examine the differences between the usage of the two. Getting Started guide The benchmark results are based purely upon the results of select statements, not the insertion of the data. The majority of applications backed by a SQL database are read heavy, not write-heavy. Additionally, rust-postgres relies heavily on dynamic dispatch for bind parameters. This means that for queries with an excessive amount of bind parameters such as batch inserts, its performance was reduced to a point that I didn’t feel was a fair comparison. Setting up data We’ll look at two benchmarks. The first one will set up with some number of rows into a single table with 3 columns, and then perform or equivalent. The second will use two tables, with more data, and a join between the two. This is the setup for Diesel: SELECT * FROM users The definition of is at the top and looks like: NewUser The comes from the crate, and generates the appropriate code to use this struct in an insert statement. We know the database schema from a line at the top that looks like which will load the database schema at compile time. Using a vector or slice of for a batch insert works automatically. We’re doing an on the result to double check that we actually inserted the number of rows we expected. #[derive(Insertable)] diesel_codegen infer_schema!("env:DATABASE_URL") NewUser assert_eq! The setup for the rust-postgres benchmark is a bit more complex. Of course this is always going to be a bit more verbose, since we have to construct the SQL manually. For batch inserts, this means lots of dynamic query construction of bits of SQL that are nothing more than which is always difficult to read. This is to be expected, rust-postgres isn’t trying to be a query builder. However, the hoops we had to jump through with the bind parameters was surprising to me. ($1, $2) The rust-postgres crate defers the serialization of the bind parameters as long as possible. However, it also doesn’t provide any data structure with which to hold the bind parameters. This means that we’ll have to stick them into a list of trait objects, even when all the binds are of the same type. This also means that it’s relying on dynamic dispatch, which will severely hinder the ability for the compiler to optimize the serialization code. The API provided by the rust-postgres crate seems like it’s probably fine if you’re building simple queries or if all your bind values are hard coded or simple borrows from something that’s already in scope. But once you’re doing anything dynamic, it’s quite hard to figure out exactly what to do. It took me quite a while to figure out the exact incantation I needed to construct the borrowed bind params there. Finally, since we’re just operating on simple SQL strings, we also need a check to make sure we’re not trying to insert 0 rows. Since rust-postgres only deals with raw SQL, it would have no way of understanding our intent to handle that case automatically for us. Simple Query Execution For the first benchmark, we are going to execute or equivalent, deserialize all of the rows into a , and then check that the length of that vector is what we expect. The struct definition for both benchmarks looks like this: SELECT * FROM users Vec<User> In the Diesel benchmark, that struct is annotated with , which generates the code to deserialize the row into the struct. The benchmark for Diesel looks like this: #[derive(Queryable)] One point of note is that the query this generates is slightly different that you would write yourself. The exact query is . We have to add a turbofish for here, since we’re never using the vector and the compiler wouldn’t be able to figure out the type. SELECT "users"."id", "users"."name", "users"."hair_color" FROM "users" ::<User> The rust-postgres benchmark is somewhat similar: One point of note is that we’ve written the deserialization code inline, rather than extracting a function called or similar. Creating that function is a common pattern in code using rust-postgres in the wild, but it’s ultimately quite fragile. Outside of this one query, we don’t know whether the columns have been renamed or not. As we’ll see later, a rename is often required. We also don’t know if this code appears inside of a join or not. If it’s on the right side of a left outer join, we’ll need to return instead. Since a function would be of limited reuse, I’ve opted not to extract one. User::from_row Option<User> User::from_row We could also gain some improvement here if we were to list out each of the columns explicitly, and fetch the result by index rather than by name. The goal of this benchmark, however, was to write code which from the user’s point of view takes the same amount of effort and does approximately the same thing. Fetching results by index is extremely brittle, and since the type knows nothing about the underlying SQL type of the data, it’s extremely easy to accidentally deserialize junk data into the wrong type. All code I’ve seen in the wild accesses fields by name, and that’s probably the right decision. Row These were the results for the “simple query” benchmark. There’s a good bit of variance due to the overhead of executing a query with postgres, but Diesel consistently came in at between 25% and 30% faster for every run. Complex Queries For the second benchmark, we’ll get a little more complex. For the data, we’ll alternate hair colors for users, and give every third user a post. This is the setup code for Diesel. For , we’re working with mostly static data. is to work with both owned and borrowed data, so you can use whatever is most convenient for that situation. In the case of where we were generating dynamic strings, it was much easier to put the result in an owned string. NewPost #[derive(Insertable)] designed NewUser The rust-postgres setup is similar to the first benchmark as well. Collecting the bind parameters for the posts query was even more difficult than the first benchmark. If the data was just *a bit* more static, we would have been able to put it into a off the bat, as its author seemed to have intended. However, we have to add 1 to the counter to get the , meaning that we have a dynamically constructed value. Since this time the types of the bind parameters are different, we have to box them up to get a single type for the vector. Even after that though, we still need the second iteration to go from to which finally we can borrow to the specific that rust-postgres wants. Vec<&ToSql> user_id Vec<Box<ToSql>> Vec<&ToSql> &[&ToSql] The query for the second benchmark is or equivalent. The code for the Diesel version looks like this: SELECT * FROM users LEFT OUTER JOIN posts ON posts.user_id = users.id WHERE hair_color = "black" ORDER BY name DESC You’ll notice that we’re never specifying the clause for this query. The information on how to perform the join is generated by an annotation on that looks like . We assume by default that the foreign key is in the form . If you don’t use this convention, or have a more complex join, it’s an easy default to override. ON User #[has_many(posts)] parent_id The rust-postgres code for this benchmark looks like this: The query here is much longer. We need to list out every column manually, and alias them so we can be sure we’re fetching the right column later. The API provided by rust-postgres does not let you specify the table name for the column. In the case of conflict, doing will silently give you whichever column came first, with no indication that you might be using the wrong data. row.get("id") id We’ve once again performed our deserialization inline. This example demonstrates my point from earlier. The common abstraction that many codebases use is quite fragile. Unfortunately, the rust-postgres crate doesn’t provide the APIs needed to write generic deserialization code for these sort of cases. from_row One high point for rust-postgres here was that this was a much easier query to execute than the rest. All our bind parameters are static, so we were able to write it inline with the query. I believe this is the type of case that its author optimized for, and it works quite well when you stay within those boundaries. The results of the second benchmark were: Conclusion Hopefully this helps to illustrate some of the key differences between Diesel and rust-postgres. Despite the focus on remaining lower level than Diesel, rust-postgres does not provide any improvement in performance over Diesel. It should be noted that the rust-postgres benchmarks compiled in 2.76 seconds, while the Diesel benchmarks took 3.4. I expect that gap to increase on large codebases. The binary for the rust-postgres benchmarks was roughly 25% larger than the binary for the Diesel benchmarks, and I would expect Diesel’s binary size to remain smaller regardless of the size of the codebase. I truly believe that the safety guarantees that Diesel provide increase developer significantly. It took me many tries to get the rust-postgres benchmarks to actually work. The feedback cycle of waiting for the runtime errors to tell me what to do, assuming the message was helpful at all, was quite slow compared to the quick compile-time feedback given by Diesel. productivity If you haven’t already given Diesel a try, I hope you’ll take the opportunity to do so over the holiday break. You can learn more at http://diesel.rs Thanks for reading! is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Fetch

Comparing Diesel and rust-postgres

Prelude Here goes the TL;DR (believe me, it is the TL;DR) version of my story . . . I always loved science. When I was about 12 my parents got a computer with Internet access. I learned to program the hardest way posible (if you want to know, I heard about hackers and the papers I got were about reverse engineering, so my first language was x86 ASM via debuggers. IMHO the best thing to understand computer, I don’t regret that). After not knowing anything I get the sensation of power and I became addicted to . As time passed I learned about web technologies (HTML, CSS, JS), backend (PHP & SQL), Sysadmin (Linux, bash, the life inside a terminal) and the must-know (C, Java). I learned a lot more stuff, but this is the short version of the history. programming All of this was before 2010. Things were pretty simple in those days. I entered college that year and remember, I love science. Because that I studied physics, no CS. I discovered that I don’t like physics much but my real love are mathematics. Almos a year ago I get an idea and tried to run a startup. It failed but I returned to programming. Things have change a lot in half a decade. After that, I got a job in a Web Agency but was a terrible experience. We worked with WordPress and for me it wasn’t exiting. I didn’t quit, my boss moved somewhere else and suddenly all of us were unemployed. It was that bad. When I was there I met some really interesting people and we started our own company this month, but some of the people I met work remotely for startups (I live in Latin America) and they told me to look for a job like them. This is what happened in my life the last year. The experiment I decided I want to work as a programmer. People around me say I’m good at it. The problem is that I don’t know anyone outside my friends in this business, I have no experience besides my terrible job and my own experiments, I am not in USA or EU, I don’t have a CS degree (or any degree at all because I haven’t finished college but that’s another story), and I’m scare to send my non-existent CV to job boards. I have to be honest, I’m not sure what I want to do as a coder. Freelancing? Work remotely? Run another startup? Stay with my friends and run a development agency? What I’m pretty sure is that I need to know people to make any of those ideas to work. Want a job? Seek for contractors. Want to run an agency/freelancing? Seek for clients. And after meeting people I need to show my skills. I’ll do an experiment. I am going to do some networking to meet people and try to show my skills as part of this networking. This is my plan: Reach out people on Twitter. Follow them and get up-to-date with the latest news. Blog about my experiences. I am thinking of blogging in Medium the steps of this experiment and the results, and blog about technical stuff in my own blog. Blog about TDD and Python. I loved Python and I haven’t seen anything related to testing that I like, maybe this can be my contribution back to the community. Blog about JS stacks. If I could I would use Python for everything but JS is the new leader and you need to know it to be employable. Become part of the Reddit community. I’m not sure how to use Reddit or how it works, but for me this point means looking for interesting post and comment on them. I want to join the discussion with people that don’t get comments because I know how it feels to be lonely when you post something. Some stories I’ve seen in Medium say Reddit is full of haters and flame wars. I want to participate in topics that people doesn’t find provocative but are worth discussing. Be an active member of StackOverflow and Quora. Answer at least 5 question a day. This is the best way to show your skills and help people at the same time. I even can learn a lot surfing these sites because, well, I’ve learned a lot in theses sites. Make a portfolio. I want at least one front-end project a week and two back-end projects a month. Maybe one project for every major framework, that means for me: Angular 2, Ember, React, VueJS, whatever people tell me about, for the FE; and Django, Flask, Rails, and some NodeJS (I don’t know about frameworks for Node, it seems like you glue several parts together but Express and Sails are good references points for me) for BE. Write something about Project Management. I enjoy the agile way of doing things. Maybe some portfolio projects are going to be used as study cases for best practices in project management. This is what I want to do for the next three months. I hope I can build a name for my self, meet interesting people, learn a lot about programming, and I am open to whatever may happen as a result. Maybe someone offers me a job, maybe I get a client and run my own company, maybe I find a place inside a new startup as founder. Who knows? What I am sure is that this can be a fun experiment. My first task I don’t know who is who in the different areas so my first task is to create lists in twitter for every topic I’m interested in, add people, and ask them to recommending me more people to follow. This looks like a good way to start a . I will blog about the result in a couple of days. Any suggestion about what else should I do is welcome. network

Glue

How to networking as a self-taught developer, a real-time experiment

HackerNoon Tech Stories Archive December 10th, 2016

Developers, it’s time to take a second look at Microsoft

@samjarman
Sam Jarman

Asycn Await BIBLE: Sequential, Parallel, Nest, Dynamic and Error Handle in Javascript

@peterchang_82818
Peter Chang

5 reasons every entrepreneur should start blogging

@shlominissan
Shlomi Nissan

Why I picked nodejs for my startup

@MostlyHarmlessD
Dom Barker

Building ethical environments for people.

@wbelk
William Belk

⭐️ On the Exponential View

@azeem
Asad

Build a Node.js Single Page Website in 4 Steps

@carsoncgibbons
Carson Gibbons

Automation will end Front-end Development

@orarbel
Or Arbel

Comparing Diesel and rust-postgres

@sgrif
Sean Griffin

How to networking as a self-taught developer, a real-time experiment

@gilmrjc
Gildardo Adrian Maravilla

HackerNoon Tech Stories Archive December 10th, 2016

@samjarmanSam Jarman

@peterchang_82818Peter Chang

@shlominissanShlomi Nissan

@MostlyHarmlessDDom Barker

@wbelkWilliam Belk

@azeemAsad

@carsoncgibbonsCarson Gibbons

@orarbelOr Arbel

@sgrifSean Griffin

@gilmrjcGildardo Adrian Maravilla