Differentiating between a great idea and a terrible idea. How Do You Know When You Have ‘The Big Idea?’ I’ve had some good ideas in the past. Of course, by ‘good’ I mean shit and by ‘in the past’ I mean a few years ago. As a matter of fact, I can clearly remember in high school having a new terrible idea nearly every week. There was a time when I convinced myself I had the greatest idea of all time. I had just finished watching a documentary on how bad sugar was for you, and I decided right then and there — I was going to be the Willy Wonka of organic, sugar-free, all-natural snack bars. It pains me to tell you this today, but ‘Kind Bars’ kind of stole my idea (get it). . Bastards Hey, That’s My Idea! Have you ever seen something and heard someone say, “ ” Hey, that’s my idea! They stole it! I used to be the type of person who would say things like that. I would have an idea, think about how great of an idea it was, and then forget about it. The only time I would remember my ideas was when I saw someone else had built it. At which point, I demanded the financial compensation I so rightfully deserved. In reality, none of my ideas were ever great, or even mediocre. Although they weren’t great, the mentality I had set me on a path of destruction where I couldn’t distinguish between a great idea and a terrible one. My thinking was toxic because I had no real intention of following through on any of the ideas I had. All Talk No Walk I wasn’t the type of person who had these terrible ideas and kept them to myself. Rather, I would have one of these terrible ideas and then tell everyone how great it was. I would go on to tell them how I was going to build my idea into a glorious kingdom the likes of which . even Zuck would be jelly of The next week, the same people would ask me how the idea is going. I would proceed to tell them I had a better idea I was pursuing now, which would be infinitely better than the last one I told them about. This never ending cycle never kept me committed to anything. It Begins With Self-Awareness I was oblivious to my toxic thinking, until someone I respected deeply stopped me mid-sentence one day. While we were having a conversation about another shit idea they said to me, “ ” You never follow through. I paused for a second (I was a bit shook), and began to rebound with a big ole’ ‘ ’ statement. They interrupted me again and said: “ ” but You never follow through. I stopped, took a good hard look at myself, and admitted, “They were r_ight._” At that moment, I realized I had been burning all my time on ideas I was never going to follow through with. I then vowed not to put any time or effort into any idea, unless it was a great idea. What Makes An Idea Great For me to be able to acknowledge what a truly great idea was, I had to admit to myself every idea I had up until that point was shit. Once I stepped back and looked at my ideas, it wasn’t hard to realize I was being naive. Before, I was so infatuated with the concept of having a great idea, that I fooled myself into thinking every idea I had was great. I decided for an idea to be considered great; it would need to be a few thing: - (I can’t just say, I am going to build the Hyperloop!)- (If no validation exists, it must be created before pursuing it any further.) - (It has to be able to grow substantially.)- - It needs to be something I have a practical understanding of. There needs to be some form of validation for it. It needs to be scalable. It needs to be something I believe in. If it is an idea I want to pursue, I have to go all in. The Idea After a few years of patiently waiting, I was sitting in my kitchen one afternoon. I was thinking about disruptive technology I was working with and if similar concept could be executed in different industries. All of a sudden, the idea hit me like a ton of bricks. I instantly knew — I finally have ‘the idea’ and I have no choice but to pursue it. Here’s my idea.

Instantly

How I Decided My Idea Was Worth Pursuing (I’ve Had A Lot Of ‘Ideas’)

I released to the world. The app is called Lintly, and it is a code quality checker that helps keep codebases squeaky clean. A few weeks ago a little web app Lintly is a name I’m really happy with. It’s short, it’s a word you won’t find in the dictionary, and it evokes , which is its purpose for existing. But perhaps best of all, I was able to get the URL lintly.com! 🎉 code linting In this article I will go over the steps I took to brainstorm and ultimately decide on a name for the app. It is my belief that following these steps can make the entire process much simpler. For the rest of the article I will use the word “app” to mean an app, a startup, or a side project. Heads up: What you’ll need First, let’s gather some resources to help us name the app. Make sure the following items are handy: A notebook A (you can’t go wrong with a ) pen Pilot G2 A web browser Thinking up a name Below are 7 steps you can take to help you come up with a name for your app. They should be followed in order. Step 1: Write one sentence that describes what your app does The first thing you should do is write one short sentence that explains what your app does. You’ll use this sentence to help come up with the words that will form the name. After writing your sentence, underline the in the sentence. These are the words that best relate to your app. key words For Lintly, I came up with the following sentence: __________ tracks your code quality and reports any violations. In my example, I underlined , , , and . In retrospect, the word “code” is probably too generic and “violations” would have been a good one to underline. The point is we need some words to start with. tracks code quality reports Step 2: Come up with a list of base words Next, it is time to come up with some that can be incorporated into the app’s name. So brush off that dusty ol’ thesaurus or head over to . base words thesaurus.com To create your base words, enter each of the words you underlined in step 1 into thesaurus.com. For each word, read the list of synonyms and write down the ones that you think could potentially work in a name. At this point you should be very liberal with the words you consider; if you’re on the fence then go ahead and write it down. Here are some of the base words I came up with: clean, sweep, neat, pure, trim, crisp — these all related to and quality cleanliness score, grade, rate, tally, summary — these all relate to and reporting scoring grumble, declare, proclaim, inform — these all relate to and tracking notifying Step 3: Come up with accompanying words Lots of companies and apps have names that are one word. Twitter, Pocket, , and come to mind immediately. Other apps combine words or portions of words to make one new word. Some examples would be Netflix (“net” + “flix”) and Feedly (“feed” + the suffix “-ly”). Google Amazon For step 3, write down as many that are related to your app. These words are typically: accompanying words is a common one, as in Lintly or Feedly. is also common, as in GitHub or ZenHub. Finally, the suffix , as in Quizlet. Suffixes. -ly -hub -let but aren’t a main focus. I added “git” and “code” as accompanying words for Lintly, even though the main focus of the app is on cleaning and quality. Words that relate loosely to your app Tip: For help coming up with accompanying words, look to your browsers bookmark bar. There are likely several websites you visit that have suffixes in their name. Step 4: Brainstorm Steps 1–3 are all about providing input for this step. This is the classic brainstorming step. Use your app’s sentence, base words, and accompanying words to think of as many company names as you can. Combine base words and suffixes. Combine base words with other base words. When you think of new words or themes during brainstorming then be sure to write them down in the base words or accompanying words sections. Here are some other things you can do in this step to come up with a name: Misspell words (Netflix, Reddit) Remove letters (Tumblr, Toggl, Modernizr) Create a portmanteau (Pin + Interest = , Code + Academy = ) Pinterest Codecademy Add numbers (37signals) Change your base words into another language like Spanish or French The notes I took when thinking up a name for Lintly Step 5: Narrow the options down Now it’s time to narrow down the names you came up with while brainstorming. There are a few criteria I like to use to easily get rid of some of the names: . These can be names that are too generic, too long, or don’t make sense. I also marked off a few names were too negative. Remove names that immediately stand out as bad (you should really love the final name you choose). Remove names you are on the fence about . To find this out, go to and enter each word into the search bar. Keep in mind there are other possibilities for a domain, like using a .io or .net domain instead. You could also prefix the domain with a word like “get” (getbootstrap.com). Remove names that dont have a .com domain available namecheap.com . Of course, this is only if Twitter is important to you. If it is and you can’t find a decent alternative then remove the name. Remove names whose Twitter handle is unavailable After all of this you should be left with a few decent choices. If not then go back to Step 4 and start brainstorming again. Step 6: Sleep on it! There is no need to make a decision right away — in fact, you should sleep on it! You may really like or hate a name at first, but giving it a night or two might change your mind. Take a night off and look at your list the next day. Do any names stand out to you now? If so, then great! Now it’s time to… Step 7: Pick a name There is nothing left to do but choose one of the names. If you are on the fence about the name then it’s probably best to mark it off and go back to brainstorming. But if you truly love one name more than all the others then congrats! You have a name for your app, your side project, or your startup. Conclusion Naming an app doesn’t have to be hard. The trick is to clear off your schedule for about an hour and focusing on the task at hand. If you brainstorm long enough then there will be lots of input. Combine the input in different ways and eventually you’ll have a name that you love. Thanks for reading, and good luck with your next gig! If you’re a Python developer who wants to keep track of their code’s cleanliness then check out my latest project, Lintly . You can also connect with me on Twitter @gmcconnaughey or see what I’m up to on GitHub .

Amazon

Google

Netflix

Twitter

A Quick 7-Step Guide for Naming Your Next App or Startup

I recently saw this video on the : Scratch website The ability to code computer programs is an important part of literacy in today’s society. When people learn to code in Scratch, they learn important strategies for solving problems, designing projects, and communicating ideas. There is a clamorous call for everyone in our society to learn how to “code” because it’s the new “literacy,” because we live in a digital world where everyone relies on software in one way or another. Mitch Resnick suggests that we can “code” programs using Scratch to express our creativity and learn important skills. I thought it was time to put a new perspective on this matter. First of all, expressing our creativity in software is nothing new. We’ve been doing it for a long time when we create photo-quality images, when we make videos and animations, when we produce our own music, when we write blogs, when we create our own websites using WordPress and Wix. Now, we can code programs using tools like Scratch. visual programming But is visual programming what is meant when digital experts exhort us to learn how to “code?” Is this why so many beginners are seeking programming instruction from coding academies and bootcamps? Of course not. The kind of “coding” that we do in IT using languages like Java and Python and Ruby is like visual programming. The program code we write is usually very complex and bug-ridden. We have to spend many hours and days, and sometimes even weeks, arduously trying to diagnose and repair software defects. These are not tasks for the faint of heart. nothing I find the term “coding” rather insulting, too. in a programming language is a small part of , which is a very demanding engineering discipline. I’ve already alluded to software , but there are other vital steps to programming as well, such as solving engineering problems, , applying sophisticated data structures and algorithms, performance , development tool installation/configuration/updates, and software . Users of Scratch, or any other similar software, are pretty much insulated from all of these concerns. Visual programming is intended to greatly simplify the process of software development so that you are never bogged down by all-night debugging sessions and month-long coding operations. Visual programming is easy because of many simplifying assumptions and restrictions; it lacks the flexibility and versatility of traditional programming methodology. Coding computer programming testing and debugging program design and architecture optimization deployment In the real world, programming is hard. Bloody hard. Is this what everyone in our society is supposed to learn as the new literacy? Is computer programming using Java or Python or C++ in any way comparable to reading, writing, and arithmetic? When you free yourself from this delusional view, you come to realize a great truth: They may use Scratch or a similar product, and in that sense they’re “coding.” But this is so far removed from what we understand as computer programming that the call for everyone to learn how to code is utterly insane. Most people in our society will never have any need to write a single line of code in their life. Learning to solve problems and communicate ideas Supposedly, coding also teaches you new problem-solving strategies and a new way to think. I have no doubt that this is true. But guess what? Nearly any intellectual activity in life teaches you similar lessons. Learning to play chess also teaches you how to solve problems, especially problems of logic and tactics and strategy. Learning mathematics and science similarly teaches you how to solve problems. So does learning to play a musical instrument. So does learning to solve logic and math puzzles. So does learning philosophy and history. Hell, so does woodworking and auto mechanics. Computer programming is not unique in any way. Logic is logic. The ability to reason is common to all activities. Should everyone in our society learn how to play chess or a musical instrument, or study astrophysics? So can we all please stop this nonsense? Stop telling everyone that they should learn how to code. Stop telling them to learn JavaScript or Python or Java. If they want to learn how to play with Scratch or other visual programming tools, that’s fine. It’s just an extension of what they’ve been doing all along. But computer programming is a whole other ball of wax.

Ball

What does it mean to “code?”

When we claim Code Valley’s Emergent Coding represents a new industrial revolution in software technology — a true watershed development for the field — we it. To illustrate its impact, let’s take a trip back to 1914. mean **A tale of two cars**Andreas, a thrill-seeking chap in Frankfurt, takes the fifty-mile trip in a bumpy carriage to Mannheim, arriving a whole day later to purchase a gorgeous gasoline-powered motorcar at Karl Benz’ factory. It costs 10,000 marks ($2500), breaks down once a week, and costs a fortune to maintain. Over in downtown Detroit, Michigan, dashing mover and shaker Bill visits a showroom to check out the latest Model T, produced on Ford’s brand-new automated conveyor-belt assembly line. It costs at $250, is dirt cheap to fix, and is by far the most dependable automobile ever made. ten times less **The assembly line that rewards creativity**Ford’s business genius was in focusing his company’s engineering talent as much, , on the manufacturing process itself as on the vehicles produced — like Elon Musk’s custom robots for Tesla Motors today. if not more Code Valley brings the assembly line to 21st-century software production in all its glory, spreading its benefits to the digital world — with compensation for highly skilled, entrepreneurial developers rather than low-skill factory workers. In addition, the Emergent Coding paradigm incorporates sophisticated customization options than those available to today’s car buyers, who are used to tailoring vehicles with the click of a mouse. even more flexibly What makes the software development “emergent” is the secret to how Code Valley achieves this feat. **It’s robots all the way down**Utilizing the smallest, most generic components available — processors, gears, servos — suppliers create more specific components, out of which others produce still more specific ones, all the way to the suppliers who assemble the robots used to create a fully customized consumer end product: your shiny new auto. Similarly, Emergent Coding spreads out engineering responsibilities among a distributed group of developers, participants in the Code Valley ecosystem. Some devs specialize in the lowest-level elements designed for bare metal, while others will work in the rarefied atmosphere of the most abstract layer, on which end users actually pull the levers to define their requirements. **The virtual assembly line that reconfigures on the fly**The way Code Valley allows theoretically infinite customization is the heart of the system: a virtual assembly line that, instead of having a central conveyor belt running down the middle, immediately for every “car” that is built. configures itself anew How is that possible? **Translator for hire**That’s where those robots come in. Each one is designed to capture requirements from either a user (at the top layer) or from other robots, and them into a form the next layer of robots down can work with. translate In the Code Valley ecosystem, we call these robots . Each Agent — which was created and is fully owned and controlled by a participant like you — translates requirements recursively down the supply chain until the last, base layer of Agents does the final translation to binary code. At that point, the entire virtual assembly line collectively returns the final executable to the end user. Agents **Show me the money**Now let’s fast-forward all the way to 2019. Bill’s great-granddaughter Charlotte currently spends $10,000 a year for a license to use business management software at her auto-detailing shop and wants something cheaper and more customizable. She loads up Code Valley’s software Agent in her browser and defines the requirements for her billing, orders, and scheduling systems using its clear, simple UI. auto retail service Charlotte is informed that it’ll cost $62 in bitcoin and take 51 minutes to build; she gladly shoots some coin over and clicks the “build” button. An hour later, she’s running her new, custom auto detailing executable — no installation or license needed. A few months later, Charlotte realizes she’s missing out on a lot of business from Bitcoin users. So she returns to her saved requirements in Code Valley and adds the Bitcoin support customization option, seeing that this time it’ll cost her $74 worth of bitcoin and take 57 minutes. The new billing and accounting systems are now completely integrated with Bitcoin at Charlotte’s Auto Detailer. Emergent Coding will make customizing software for end users this cheap and easy. But what’s in it for the devs? Just think about where that bitcoin Charlotte paid is going — the top-level retail-service Agent took a fraction and paid the rest to the Agents it depends on. Those Agents each took a fraction and paid the rest to Agent suppliers, and so on. Each Agent is owned outright by a developer who receives bitcoin every single time it’s used in a temporary assembly line. Rather than being contracted over time to work on (and maintain) a project like coders today, developers in the Code Valley ecosystem get paid an end user triggers a software build with their Agents. their every time **No time like the present**Although the easy-to-use end-user-facing layers of abstraction in Code Valley have not yet been built — it can’t cater to Charlotte quite yet — the path is clear. With every new Agent created by a developer, we all move closer to that world and its boundless demand for custom software. Just imagine how competition of Tesla’s manufacturing robot components — and therefore high quality and low price — would skyrocket even more if each supplier was incentivized with a payment every time a car was produced using that hardware. That is the effect will have on software production, through the magic of Emergent Coding’s instantly reconfigurable assembly line. Code Valley Take it for a spin — build a small program with already deployed Agents . here Create and deploy A_gents of your own_ by requesting an invite . here

Assembly

Tesla

It’s robots all the way down

Completed != Validated

Disclaimer: I used to be a Senior Product Manager in the JIRA team at Atlassian, where I launched a new project and task management tool for business teams — JIRA Core. These thoughts and opinions are my own. At USD 425 million, is ’s — that number represents 7.7% of their total market capitalisation, and looking at the of their cash assets (USD 266 million on 30 September 2016), it’s probably fair to say that the USD 360 million cash component almost broke the bank. The earnings call on 19 January 2017 should be pretty interesting, but shareholders seem to be positive about it. Trello Atlassian biggest acquisition yet last reports The question is, why would Atlassian spend that much money on a product that is in some ways very similar to the ones they already have? After all, Trello helps teams manage tasks in a visual way, but JIRA already has 2 types of boards that not only do the same, but are vastly more sophisticated in terms of functionality and the underlying technology. Cloud First When Atlassian first released JIRA in 2002, businesses still preferred running their own servers to keep software and data secure. While Atlassian does have a cloud offering, customers do express some room for improvement. Trello, first released in 2011 when the IT landscape and zeitgeist was already changing, was built for the cloud first and for the cloud only. This allows Trello to experiment and iterate much faster, avoid a lot of the complexities that come with maintaining Cloud and Server products at the same time and it also allowed them to build a simpler way to connect with other apps. The Atlassian Marketplace lists about but over 100 more for JIRA Server. The limited set of APIs for JIRA Cloud compared to JIRA Server could be one part of the problem. For Trello, there is no way to see publicly how many integrations have been built, but given the lower barriers it is unsurprising that “trello integration” brings up almost twice as many search results on Google as “jira integration”. 330 add-ons being available for JIRA Cloud Trello is embracing the Cloud and their team’s experiences will no doubt lift the game for Atlassians other products. Will we see Atlassian building a server version of Trello, ? Only time will tell, but there is an important reason that makes me doubt it. like they did with HipChat Simplicity > Feature list Atlassian has traditionally followed a bottom-up adoption model. It is a fundamental part of their business that teams can simply adopt software, tinker with it to adapt it to their needs and run with it — no enterprise sales cycle required. When Atlassian started, their customers loved this new model, especially technical teams which just wanted to get on with changing the world instead of sitting in sales meetings. Atlassian went for the longest time without any sales people — it is not despite that but because of it, that their main products like JIRA are so well known and loved by teams all over the world. However, from having built several different products myself, I know that one thing has changed over time — people’s willingness to tinker with new products. These days, if something doesn’t “just work”, people lose interest very quickly. Our lives are faster and we have simply very little time to waste on figuring out how something works. Meanwhile, JIRA’s functionality has expanded drastically. JIRA’s biggest strength, in my opinion, is how flexible and adaptable it is. But at the same time, that is its biggest weakness. At Atlassian’s annual customer conference, Summit, we showcased some of the most common use cases. Although JIRA was originally built for software teams, there are many marketing, legal, HR, sales and other teams embracing it. Now, in Atlassian’s , they mention how Trello’s “card system is intuitive, easy to use, and instantly familiar, which has made it extremely popular with teams across marketing, legal, HR, sales and beyond.”. acquisition announcement It looks like the patterns are the same — these teams need flexible task management tools, but the new breed of teams want to use something that “just works”. Want a hint that Atlassian thinks this is the future? In their own announcement, they encourage their customers to create a Trello account. But in there is no call-to-action for creating a JIRA account (even though revenue wise, this might be an up-sell as JIRA has no free version). Trello’s announcement MAU — Monthly Active Users As the acquisition announcement points out, Atlassian and Trello have identical milestones towards achieving our missions: for our tools to be used by 100M people. What a superior experience and low barriers to adoption in a market that is has a fundamental need for task management solutions create is magical growth and momentum. And with that comes marketing power — so it’s no wonder many companies have MAU as their top metric. With Trello’s user base, not just in terms of raw numbers but also in terms of their demographics, Atlassian can secure its position with small, forward-thinking teams. They will also be able to expose their products to individual users who use Trello for personal projects. These individuals will now get exposure to Atlassian’s other products and will be able to take these into the companies they work for or with. The more products of a brand a customer uses the better — that’s how Apple, Google, Microsoft and Facebook became some of the most valuable companies in the world. It’s no surprise to see Atlassian, a multi-product company from the very early days, heading down that route. Verdict Whatever the future holds for Atlassian, JIRA and Trello, this is exciting new with lots of opportunities and upsides for everyone involved. Now several other companies will have to up their game to keep up. Asana was very late to introduce boards like Trello and JIRA Core already had, they might be in an even more difficult position when Atlassian combines Trello for example with HipChat to create a fully integrated task management and communication experience — something they . already announced For Atlassian, I believe this was exactly the right move. One of the questions that remain is: With that much overlap between their tools, how will a user who has not heard of neither Trello nor JIRA or Service Desk figure out what’s best for them? How will JIRA users decide between JIRA Agile boards and Trello once the products are integrated? There might be a little more tinkering we will have to do after all, but whichever one you end up using, these tools are going to become a whole lot better — which is going to be great for every team! PS: I regularly share my lessons learned from building, managing and growing products at www.productrise.com . Also, if you are stuck with your product, team or personal Product Management journey, reach out to me any time. I’m always happy to just have a chat.

Apple

Asana

ATLASSIAN

Facebook

Microsoft

Trello

What the Trello Acquisition Means For Atlassian

Intimate behind-the-scenes footage from the Yahoo renaming meeting

Credit: Clem Onojeghuo Yesterday, I’d just shaved and was cleaning up the inevitable beard related . As I was doing so a question came to mind: How much water would I use to wash the hair away? hair aftermath It’s quicker to wash the hair down the sink with more water, but more water will be used. What’s more important, time or water used? We all face questions like this regularly. It’s a part of every day life. Will I get a taxi or walk? Will I buy on credit or wait and save? Will I be honest or lie? Similarly, we all have to decide how much time we’ll trade for money. There’s a balance to be found, we need both, and we each have to work out our own tipping point. In amongst it all, is the underlying question: what are you really optimising for? This question reminded me of a quote from : Jason Lemkin It begs the question, are we optimising to win at business or win at life, win at family? What does our success criteria look like? For us, we’re still in the stage of optimising primarily for learning. That may never change. If its a choice between learning now or money now, learning is often the best route as it enables us to earn more money later. We’re in a fortunate place where we earn in our day jobs and work on our own stuff in the evenings and weekends. As a result, when opportunities come along that benefit us in terms of learning more than money, we can remember that learning is what we’re optimising for, so despite a business being built on financials, it may well be the right path to take. Yesterday and I were walking and talking and came onto the subject of a seed of an idea Mike had. At first glance it seemed like a bit of a distraction from our current focus. It seemed like an itch that was tempting to scratch but one we should be ignoring. Mike Having spoken it through though it turned out to be much more of a contender than first thought. It aligned with the direction we want to go in, there was a big overlap in terms of what we’ll learn in the project to what we’ll need to learn in our main focus, and it is notably smaller than our big vision. It could well be the small slice of an idea we’ve been looking for. The bottom line is that if we go ahead with it, regardless of whether it will make us money, it will at least enable us to learn. We’ll be in a better place to achieve our goals by taking this path, and at the worst it will just delay us a little. Our big goal is still to be financially independent, to support ourselves from our business. But despite that, the key for us is learning, not money. There’s a balance to be struck here. In business, the best type of learning money. That’s the validation that really matters. But despite that, what we care about, at least for now, is learning. Whether it comes from money or elsewhere, learning is still key. is Rather than focus on whether we think we’ll get a direct financial ROI from our time invested in the project, we’re asking ourselves, if nothing else, is this the best way to learn? We’ve got a to learn, so we’re optimising for that. lot Enjoyed this post? Hit the little ❤ below to let your friends know ↓ Want more? I write small weekly emails with little blog posts in like this. Signup, if you’d like, it’s free. Or ✔ me on Twitter Originally published at fredrivett.com on January 9, 2017.

What are you optimising for?

Hello My organisation had a directory structure for projects like: grunt/Gruntfile.js grunt/package.json grunt/node_modules/ web/index.html (well, .php) web/js/script.js Which had been fine with our for SCSS, JS etc. grunt toolchain When I added JSX and via I found I encountered an react browserify “Error running grunt-browserify” >> Error: Cannot find module ‘react’ from ‘/directory/of/source/jsx’ There may be a simple way of telling (or similar, I had the same errors when investigating alternatives) the location of the node_modules/ for modules, presets and plugins, but until I find out what it is, I have reorganised to: grunt-browserify /Gruntfile.js /package.json /node_modules web/index.html web/js/react-app.js And changed my to reflect that the web/* source files folder live in a child directory (web/) rather than a sibling (../web/). Gruntfile.js >> Bundle web/js/react-app.js created. I would prefer to have not moved my directories around, but for now, my OCD can live with a bit of pollution of the parent directory.

Reorganising a directory structure to solve “Cannot find module/preset/plugin” in grunt with babel…

In our determination to see more and better use of tech for good, we’ve looked to understand what have been the underlying drivers of the massive digital transformation we’ve seen in other parts of our lives. These underlying actions and conditions have enabled an incredible scale of change, and if we’re to create a similar scale of social progress, then we need to ensure the right conditions exist for such development to occur. Of course such change requires passionate entrepreneurs and teams with innovative ideas; of course effective funding and aligned investment and, of course, targeted solutions to real problems. Less ‘of course’ is the importance of — but if we can get the right conditions in place, 2017 can provide that. good timing We’ve discerned that are needed if we want to create something comparable to the huge impact digital has created across other areas of our lives. They’re the underlying conditions that allow us all to practise in a way that can bring massive change. . six things Six tenets for tech for good We’ll look to ensure that each of these elements are built within our activities, partnerships and conversations. If we can all do this — then we’ll really see the acceleration of social impact through digital technology. We’d love to hear your thoughts, challenges and additions to these, and to support them to be developed and practised. Drumroll… Six Tenets of Tech for Good A culture of reuse User led, and test-driven development Creating three strands of value Lean metrics and ongoing testing Smaller problems for bigger solutions Addressing challenges, not suggesting solutions A culture of reuse The history of computing and the giant leaps that it has powered, , asynchronous development and movements of people/organisations working on similar problems and solutions. is a history of collaboration One to add to the reading list From Lovelace and Babbage; Bell Labs and Bletchley Park; through organised cross-sector ; the homebrew hackers of the 1970s and the open source movement — digital innovation has often come about when many people and teams work on similar problems and solutions. This indicates that to see similar advances within tech for good, encouraging/supporting people who appear (at a top level) to be doing the same thing is important — even though that can be difficult in such a resource-constrained environment. research ecosystems However, central to such rapid development is that these innovators reused what had already been created. This is more than ‘ ’ building on previous ideas, this saw the reuse of hardware and code that could provide a shortcut to building solutions more quickly. From to more modern reuses of / this dramatically reduces the cost of early innovation, encouraging more (and wider) exploration. Whether you want a new , ; or even a , there will be code and platforms available that can serve 80% of your needs for low or no cost. standing on the shoulders of giants IBM open-sourcing their operating system tools functionality culture of reuse website online community quiz bot If we could reduce the cost of early stage digital innovations by creating a culture of reuse; if we could increase our confidence in the need for investment by proving demand for new services (having evidenced use with what already exists), then we can begin to create the speed and scale of impact that digital has created in other parts of our lives. Of course, this isn’t just about the digital tools, but the underpinning research too. Sharing, and searching for that which exists, increases the pace of innovation, and the effectiveness of our collective work. See for more on this! our most recent blog to both (whether as , , , etc) but also : searching for, tweaking and testing that which already exists (and giving credit to the work that has gone before). Our challenge: share our products/outputs in reusable formats research APIs open data quick wins , to develop the habits of reuse 2. User led, and test-driven development At the heart of creating effective digital products and services is ensuring that it has ‘product-market fit’. That means the thing being created attracts users in a way that generates income. Startups continually test this fit, changing the product, the language and/or the price until the fit is made. Digital offers a unique way to do this easily, and relatively cheaply — providing cheap digital tools backed up by analytics programs to see how people behave with your new product. Our Fusilier charities take a user led, test-driven approach to everything they create In Fuse we test/talk with five people from day three, and aim to create prototypes to understand people’s behaviour with our ideas as quickly as possible. This test-driven approach continues throughout the three month programme and is baked into ongoing product development — ensuring that the products created meet the choice making and usage behaviours of our audience. This isn’t just about taking a test-driven approach to development but places the users at the heart of development — even more so than many traditional co-design approaches. Whilst we employ many co-design and participatory design techniques, all development within test-driven development responds to user’s actions rather than articulated desires. In this way their ideas, demands and behaviours are central to the work of the professional development team. A lot has been written about test-driven and lean development — but at the heart it is about building confidence in your product/service because of the way people use it. That means getting a product into their hands as quickly as possible, rather than spending too long designing what you think is most needed/wanted. to ensure all products, services and programmes are built around a test-driven and user-led process. Our challenge: 3. Creating three strands of value We’ve written lots (along with the brilliant team at ) about the vital need for every tech for good project/venture to focus on building three types of value: social value; financial value, and user value. Without articulating and developing all of these strands of value, the whole approach will fail — so it’s vital to explore and build each of these values from the start. Shift The ‘triple helix’: Social value, financial value and user value We’ve written about the , and , so settle down with a cuppa and look through it. The key points include recognising that social value will only be achieved when a product/service is created in a way that people actively choose to use it (creating user value); that you’ll need to identify to test (and give you confidence) that these values are being realised — or that they have the potential to be realised, and that each of these value can only be based on their stage of development and stability. theory the practical implications relevant metrics evidenced This is an important focus for funders and founders alike — we need to support innovators to test and develop each of these areas of value, but similarly of what can be achieved through funding. set realistic expectations to work with startups and new projects to build around these three values, and to work with funders, commissioners and investors to implement funding, support and evaluation frameworks that support such growth. Our challenge: 4. Lean metrics and ongoing testing or lean analytics are at the heart of agile development and really significant in tech-led startups. They’re the important measurement-step that links ‘learning’ and ‘building’ in the famous . Lean metrics build-measure-learn cycle Iterate your way from small short-term steps to big long-term impact, measuring as you go What’s really crucial here is that there’s an established methodology for seeing short term development within a long term aspiration (such as creating a huge impact tech company). Building on this methodology makes a that we need to realise — and also helps unlock the challenges of creating longer-term social impact by measuring and developing smaller steps towards it. valuable approach to development across each of the three values This helps ensure development is constantly evolving and focused on improvement, but also helps identify realistic expectations for collaborations with funders and investors. to build all of our approaches using lean metrics, and to work with tech for good organisations to implement and support similar approaches — creating a shared (and language) that is honest, justified and evidenced. Our challenge: measurement framework 5. Smaller problems for bigger solutions Last year we published a brief article about one particular benefit of digital approaches, that of . The core argument there is that tech for good requires big problems to be very specifically described in order for a digital solution to be created. Consider how Google returns the search result ‘most relevant’ to you. If you searched for ‘local news’ — then each of those terms has to be defined very specifically: what local means to you, what counts as news. trumpets, not trombones In analogue vs. digital, the trumpet wins In our sector we mostly focus on — those that are big, challenging, hard to understand and address. Yet a digital approach pushes us to continually rethink and rearticulate the challenge in a way that helps creates specific solutions. , , and test-driven development can all help with this, but digital approaches require a reframing and re-articulation of the problem which creates new ways of addressing them. Over time we can address lots of specific problems, rather than chasing a few big ones that can’t be overcome. wicked problems Sensing making user research to continue to be specific and focused on where digital can make a big difference, and to work tirelessly to bring that value about. Being honest about where digital has no, or limited role, and ensuring we bring multi-talented/disciplinary teams to focus on identifying and addressing important problems. Our challenge: 6. Addressing challenges, not suggesting solutions We’ve such expertise and experience within social organisations, it’s easy to see why so many new ideas, approaches and solutions are identified and developed each year. However, an important lesson from tech development is that we’re not *that* good at judging customer/user requirements, and that we need to separate our beliefs/expectations from people’s actual choice making and behaviours. Solutionising is not just a social sector problem! This returns to the ‘product-market fit’ (noted in point two) where tech ventures can quickly and easily test user’s behaviour with their ideas before developing the most in-demand parts. If we can find a method to test our solutions, and to be prepared to change them — quickly — based on the behaviours and choices of our ‘audience’, then we can really begin to address big social challenges. The digital community takes such an approach using approaches to ensuring the best product/service. If we can develop similar approaches, then over time we can really address big social challenges, not by following our initial solutions, but by following a test-driven methodology to addressing challenges. lean and agile This is more than a challenge for charities/ventures to adopt test-driven approaches. It requires funders to support organisation to address challenges, rather than to deliver solutions. This means being comfortable that solutions/interventions will change based on feedback/user-testing; being comfortable that the solution might change considerably from the original expectation. This doesn’t mean funding open explorations, but to use a tested methodology to find (and then deliver) the right solution. It might seem more open — even more risky — but it enables a better targeted solution to be found and created. supporting trusted organisations to continue to use a test-driven approach to addressing challenges. To work with funders, investors and social organisations to understand and implement trusted methodologies to rigorously find the right solutions to big social challenges — taking into account the accountability and reporting differences that this may bring. Our challenge: Here it is again, but bigger and more colourful :) . Each of them big and important — but together they create the undercurrent to power a wave of digital innovation that can have a huge impact on the social challenges facing individuals and our communities. If we can create this undercurrent, then the scale of that impact can be as big, and as transformative, as we have seen in so many other areas of our lives. Six things Just imagine the possibilities if we can really create such a change. These six tenets are the parts which shift that imagining into a focus for 2017.

Funding

ProgrammableWeb

YouTube

Six tenets of tech for good

Photo Credit Paul Bence https://unsplash.com/@bency When I first started back in 2007 I thought it would be nice to have a blog to capture my thoughts and chronicle my work. Femgineer I had no grandiose vision for it. It was just a side project for me. Over time my blog began bringing in opportunities to speak and teach. I enjoyed all those opportunities. One gig would bring in another, and my calendar filled up pretty quickly. Soon I began to realize that my actual work was suffering from all the gigs my blog was bringing in. I didn’t have the time to devote attention to both. But I couldn’t say no to the opportunities, because I just loved the chance to connect, speak, and teach people. I had to make a hard decision: quit building software products and start speaking and teaching full-time. I mulled over the decision for awhile. I worried what my parents would say, they’d question why I had bothered going college to study engineering. I worried about what my friends would think, they’d probably poke fun at me and all my speaking. But two things were crystal clear in my mind: I loved doing it and there were people out there who wanted it. So with that, I quieted the critical voices in my head and said yes. The voices don’t go away, in fact they only became louder My parents asked if I was able to pay my bills. Friends started recruiting me to come and be an engineer at their company thinking that I was somehow desperate for work. While others were baffled about how I could transform a blog into a business. At first, I was annoyed that they couldn’t see the value in the work that I was doing, and questioned my ability to put a roof over my head. There would be moments where I’d have a rough day, and their questions would creep into my head. Eventually, I learned how to resist all the voices and focus on my work. Calling it work helped, because it meant I was taking it seriously, and the funny thing about others is, when you take your work seriously, they learn to take it seriously too. Now an offhanded comment doesn’t bother me because in the famous words of MC Hammer I am: He probably felt the same way after people making fun of his lyrics and parachute pants. “Too legit to quit!” It’s taken me years to quiet the critical voices and . feel confident about my work Part of the struggle is fighting conventional wisdom that tells we need degrees, accolades, and a steady paycheck. An unconventional path is rife with uncertainty, criticism, and instability. And once you’ve gone down a conventional path, changing your mind to pursue one that is unconventional is perceived as playful, unsteady, and unprofessional. When it finally came time to release my work into the world I feared the criticism I would face. These fears held me back for many years. until I learned how to manage them and . I resisted going after what I wanted embrace creative confidence It takes courage to pursue a , and the desire for legitimacy only make it harder. creative calling Ultimately, you have to ask yourself the following questions: Who gets to determine whether the work you want to do is legitimate, and why do they get to decide? Do you enjoy doing the work? Does it make you happy? — Just because it doesn’t initially doesn’t mean it can’t eventually. Can you figure out a way to support yourself off of it? — It doesn’t mean everyone need to find value, just some. Do other find value in it? The Happiness Project by Gretchen Rubin I loved this exchange from between the author Gretchen Rubin who is figuring out how to transition from a career in law to being a writer, and her sister who has been a writer for many years: The Happiness Project “I worry about feeling ,” I confessed. “Working in something like law or finance or politics would make me feel legitimate. legitimate I expected her to say something like “Writing legitimate” or “You can switch to something else if you don’t like it,” but she was far more astute. is “You know,” she said, “you’ve always had this desire for legitimacy, and you’ll have it forever. It’s probably why you went to law school. But should you let it determine your next job?” “Well…” “You’ve already done highly legitimate things, like clearly on the Supreme Court, but do you feel legitimate?” “Not really.” “So you probably never will. Okay. Just don’t let that drive your decisions.” Now let me know in the comments below, is feeling legitimate holding you back from pursuing a creative calling? And if you’ve overcome it, please share how, so myself and other readers can learn from your experience! Enjoyed this post and want more? Help others enjoy it too by hitting the ♡ below! And subscribe here to receive all my posts on personal growth, engineering, and entrepreneurship.

Why Our Desire For Legitimacy Holds Us Back From Pursuing Our Creative Calling

In this post, we demonstrate an idea for wear-your-pajamas-enabled video conferencing. We all know how significant non-verbal cues are for effective communication. But, audio-only calls still conference calling. With today’s , dominate tech why isn’t video the default? I suspect the answer is a combination of tech shortcomings, cultural norms, and personal preferences. I discussed some of the tech aspects I found lacking in my previous article, “ .” Today, I want to focus on 2 shortcomings of video conferencing: It’s 2016, why is video conferencing still terrible Video requires a robust internet connection — even when our own connection is sufficient, we may worry whether the people will have a good experience. Video is less private — we don’t always want to show our state of dress, our messy space, our multitasking. These issues can make us feel uncertainty and discomfort. Not emotions we tend to actively seek out. What if we could maintain much of the body language benefits of video conferencing, but significantly reduce these negatives? Video conferencing without video! What? Actually, video conferencing with . Instead of transmitting video of ourselves, a conferencing system could transmit a representation of ourselves. Using a webcam video as input, it is possible to track facial feature motion in real time. Those facial feature positions would be transmitted to other users, who would see a reconstructed animated avatar. Your webcam video never needs to leave the comfort of your own computer! avatars Proposed methodology It’s been said, “If a picture is worth a thousand words, then a video is worth a million.” I certainly don’t want to write a million words. We’ve created an example of this idea by converting the demo videos from our existing (in public beta), into simple avatars. This is a first hack demonstration, not a polished work of art. conferencing system, Locus Locus with videos (left) vs. avatars (right) Locus demo using avatars. *Best experienced with headphones* For reference, original demo with videos . here Interesting, right? But why would we want such a system? . Video conferences require roughly 100 times higher data rate vs. audio-only calls. It’s no surprise video can be unreliable! If we only transmit facial feature position information, we can reduce the “video” data rate down lower than an audio stream! . Reduced bandwidth If connectivity is good enough for an audio call, it would generally be sufficient for audio + avatar . Only your body language is transmitted, not your webcam. Increased privacy . With Locus we’re working on translating the in-person experience of being together in a room into a conferencing system. Using video feeds, we currently break the metaphor with each participant appearing in a box with their own background from their own physical space. With avatars, conference participants can all appear together in one space. Appear together more naturally . Who wouldn’t want to show up to their next meeting looking like Superman? Fun . This will depend on the implementation details of the avatar system and the traditional video conferencing system, but eliminating (sometimes multiple) video transcodings could result in lower computation and therefor increased battery life. Reconstruction could also take place for each user, allowing that user to select trade-offs of CPU vs avatar quality. Reduced CPU Sounds pretty great. Why we want this system? There could be a few shortcomings: wouldn’t Reduced communication. In counterpoint to the privacy benefit, information on our environment, bags under our eyes, etc can at times provide useful context, which may be lost. Tracking errors. Tracking facial features from webcam video is not always 100% accurate and can depend on lighting quality among other factors. Although video sharing is dependent on similar factors, an avatar system might degrade less gracefully. Creepiness / Perfecting avatars to avoid the creepy factor could be a ton of work, and may never get to 100%. uncanny valley. One webcam stream with multiple users may become a much harder challenge to address. The avatars in such a system could be designed in many different ways. Some ideas: Simple 2D cartoons with customization. Similar to Chris & JD in the demo. 3D rendered characters. Similar to Lois in the demo. Facial manipulation from an image. Use a still photo of the subject and manipulate it to match the subject’s live facial expressions. See for a somewhat creepy, but amazing example of this idea. work of Thies, et al Trade offs on avatar types We’ve created examples of these options below. The simple cartoon in its current form does lose some expression information, but could be improved. We do like the simplicity of this option — and such cartoons could be created autonomously from webcam images. Avatar option examples. The tech required to realize this proposal appears feasible. What do you think? Could avatar conference calls be the future? Share your opinion with us and optionally subscribe for updates using the form below, or here . If you like what you read, be sure to 💗 below.

Video Conferencing without the Video?

Quick — name one startup you know using a single-tenant architecture. Got one? Yeah, me neither. Multi-tenant architectures are the standard way to run a startup these days. Create a database, provision some servers, add a load balancer, top it off with some caching and call it a day. But why? What is it about multi-tenant that’s superior to single-tenant? Is it cost? Complexity? Security? Scale? Recently I started working on a new product and the multi-tenant architecture felt ungodly complex. There had to be a better solution — a quicker way to get up and running that wouldn’t create scaling issues for us later on. Now, I’ll be honest. I’ve been developing software and running websites for 15 years and I’ve never had to deal with “internet scale” concerns. Hell, I’ve barely even had to deal with caching. I’ve been working on Kumu the past five years and — — Kumu’s traffic can be handled by a single large server. It’s a powerful, sophisticated tool, and growth has been solid, but it’s simply not the kind of stuff that goes viral. outside of embeds We expect to be a different story. Compass Compass helps you visualize your Slack team’s communication. Unlike Kumu — where you start small, build up your data incrementally, and handle most calculations locally in your browser — Compass taps into a firehose of data the second you sign up and most calculations are handled server-side. Compass may never reach the scale we’re anticipating, but if it does we want to be prepared. We have , and , and , and , and we’d much rather be doing. Like sleeping. (Trying to, at least.) And if it goes viral we don’t want to be woken up in the middle of the night to put out fires. lives wives kids hobbies many other things So instead of attempting to build a system that scale, we’re putting in some time upfront to an (or at least make it somebody else’s responsibility). should design any-scale system: a system that’s built to remove scale from the equation With that goal, we’ve been exploring two potential architectures on top of AWS: (typical model supporting all teams on a pool of shared resources, such as load balancers, gateways, subnets, kinesis, lambdas, redshift, ECS, EC2, autoscaling groups, security groups, cloudfront, etc — ) Multi-tenant SAAS honestly if I were to list every AWS resource required there would be dozens of them — hence the reason for exploring the simpler, single-tenant architecture (each teams gets a dedicated EC2 instance, exposed directly to the internet, with everything running locally through Docker) Single-tenant The remainder of this post explores the trade-offs we’ve considered between these two architectures. If there are any big ones we’ve missed, please mention them in the comments! Cost As a bootstrapped startup, cost is a big one. Get it wrong and it can cripple you before you get out of the gate. Get it right and you’re off to sipping mai tais on the beach while you still look good in a bathing suit. (Or you could use that money productively to create jobs and grow the product. You’re the boss.) You’re paying a lot up front but the good news is each new customer you add drives down the marginal cost of adding the next one. Outside of customer support, adding new customers doesn’t really cost you anything. With multi-tenant architectures, the cost to run the system is fixed. It’s fixed. Each new customer requires a new instance and each of those new instances has to be paid for. Worse than that, the cost per customer actually goes up! Larger teams need larger instances. While we might be able to support teams of 10 to 20 on a t2.nano, we’ll need a much larger instance to support teams with hundreds of members. With single-tenant architectures, the marginal cost of adding new customers never goes down. So — since multi-tenant lowers cost per customer — it’s the clear winner here, right? Well… no. Not really. Besides the cost of the underlying infrastructure, there’s also these things called . And they’re expensive. humans The single-tenant architecture is a simpler architecture with fewer moving pieces. Simpler systems can be supported by smaller teams. And those teams can be made up of developers instead of dedicated sysadmins — it’s the exact same system you’re already running locally for development. Which brings us to the next concern: parity. Parity Parity is the notion of similarity between environments. One of the major downsides of the multi-tenant architecture is the lack of parity between the environments we need to support: development (everything running locally on your own machine) staging (everything running in the cloud but not designed to scale) production (everything running in the cloud and designed to scale) enterprise (everything running on somebody else’s machine) Each one of those environments is complex on its own. Add them together and it’s clear why sysadmins get paid the big bucks. You could argue that you don’t really need a staging environment. Because that’s what tests are for, ? right You could also argue that worrying about an on-premise enterprise version at this stage is premature. And in many cases you’d be right. But in Compass’s case, we’re juggling messages that contain sensitive information. And as such, we’ve already had requests for an on-premise version. Since enterprise customers are typically your largest and most loyal customers, we’d be foolish not to factor them into our initial planning. As a small team with limited resources, we think that’s pretty sweet. Single-tenant is the clear winner here since it gives you parity across all environments an easy path to enterprise. and Maintenance Maintenance on multi-tenant systems can be scary. You push out a single update, and every customer is immediately on the new system. If you botch it you take down the entire system. Been there, done that. Not fun when it happens. With multi-tenant, deploys are typically all or nothing. If you botch it, you typically only take down a single team. Instead of deploying a single app update, you’re deploying N app updates. Instead of migrating one database, you’re migrating N databases. On the surface level it sounds like this would create more work for you, but since the systems are isolated and identical most of that work can be automated. All you need is a bit of tooling to orchestrate the updates. With single-tenant, maintenance is incremental. No need to mess around with load balancers or juggle internal feature flags. A beautiful side effect of single-tenant maintenance is that you get incremental rollouts and targeted beta releases for free. Resilience Both architectures offer their own form of resilience. Each team is serviced by multiple instances, spread across multiple regions/zones, and hosted behind load balancers. A team is unlikely to experience issues unless there is a system-wide outage. Multi-tenant creates resilience at the team level. there are very few ways to take down the entire system. A team may experience problems, but it’s unlikely those problems will extend beyond that single instance. Single-tenant creates resilience at the system level. Outside of DDOS attacks at the DNS level To account for disasters, we can throw in EBS backups, health checks, and a recovery instance that can stuff Slack events into a queue until a new server is provisioned. Now we’ve got a simple, resilient system at both the team system level. and Team system resilience? Yesssss and Plus, in general, a single angry customer is much easier to deal with than an angry mob. So chalk another one up for single-tenant here. Recovery On , every project is backed by a separate CouchDB database. Over the years we’ve found this isolation extremely valuable. Sometimes we mess things up. Sometimes the customer messes things up. Regardless of who’s to blame, , rather than simply being logically isolated within a single database. Database restorations become simple filesystem copies instead of fragile, complex database queries. Kumu disaster recovery is much easier when each customer’s data is physically isolated Security As far as I’m concerned, simple is the best kind of secure. Complex systems often give the that isn’t truly there. illusion of security If everything is running locally on a single machine, and that machine is locked down with key-based SSH access, and the only other port that machine exposes is port 443 — then I’m not losing sleep at night worrying about security breaches. Yes, the machine is exposed directly to the internet. You can easily mess up either one. But as long as part of the system is exposed, direct exposure isn’t inherently less secure than indirect exposure. any If two systems have similar exposure and one is significantly simpler, I’ll go with the simpler system every time. Less surface area. Less complexity. Easier to audit. Sold. Conclusion As with most things, there’s no holy grail here. Both architectures have their tradeoffs and both are solid solutions for the right problems. I’ve always used multi-tenant architectures in the past but in this case it just doesn’t feel like the right tool for the job. At the end of the day it’s our job as engineers to find that sweet spot at the intersection between priorities and constraints. For Compass, that sweet spot appears to be single-tenant. There’s a strong argument to be made for multi-tenant too, but for now, a single instance per team looks like the quickest way to get up and running while minimizing scaling concerns. It’s also important to note that single-tenant wouldn’t even be an option if we were hoping to allow cross-team analysis. That said, : here are the key advantages single-tenant provides for Compass We can use the same docker containers we’re using in development to run things in production. We can roll updates out team-by-team as we build out new features and collect feedback during our beta phase. We can provision instances geographically close to the customer, improving responsiveness while avoiding the need for a CDN. We can ease privacy concerns by physically isolating each team’s data. And since we don’t have a free plan, we don’t mind spending a few bucks a month to support each team (especially if that reduces operational complexity and shortens time to launch). So that’s where we’re at. At this point Compass is just a prototype but we’re hoping to build out the backend over the next few weeks. If you run an active Slack team and you’re interested in being a beta tester, let me know! You can reach me at or on Twitter. ryan@kumu.io @rymohr Do you have experience running single-tenant architectures at scale? If so I’d love to hear about it in the comments below or the related post on HN !

Instagram

Slack

Zones

You are safe here

Read My Stories

Single vs multi-tenant SAAS

Note: This tutorial is an excerpt for the deployment chapter in my book . The book will guide you from humble beginnings by deploying an app to production. If you find this type of content valuable, you can grab a free chapter right now! Building a SaaS Ruby on Rails 5 Also, the beta for my new project is almost ready. If you’re losing track of pull requests, have old ones lingering around or would just love a dashboard that aggregates these requests over multiple services (Github, Gitlab, and Bitbucket), . Pull Manager check it out Deploying a Rails app can be a somewhat daunting task to get set up right on new applications, even for seasoned Rails developers. While Capistrano has been the main player in Rails app deployments, it seems to have fallen somewhat out of favor as load balancers and computing servers have gained popularity. Thankfully, has created a tool for deploying and scaling Rails web application in their eco-system. Here is an explanation from their landing page: AWS(Amazon Web Services) AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, , PHP, Node.js, Python, Ruby, Go, and on familiar servers such as Apache, Nginx, Passenger, and . .NET Docker IIS You can simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time. There is no additional charge for Elastic Beanstalk — you pay only for the AWS resources needed to store and run your applications. Getting Started If you do not have an AWS account yet, go sign up, and you get a bunch of free services for a year on specific levels(i.e t1.micro server, etc). The tutorial is going to focus on MacOS, and I can expand if enough interest is shown for windows, though most rails based commands should work on any platform. After your set up your user, get AWS’s CLI(here via brew): $ brew update$ brew install aws-elasticbeanstalk Now create the rails app if you have not already $ **rvm or rbenv optional setup here**$ gem install rails -v 5.0.1$ rails new rails5app$ cd rails5app$ git init && git add -A && git commit -m "Init Commit Message" …and now we’ll create an example scaffold $ rails g scaffold message subject body:text$ rails db:migrate$ git add .$ git commit -am "Add Messages"$ git push Alright, we have a basic Rails app needed to continue with the Elastic BeanStalk deploy. Lets initialize ElasticBeanstalk $ eb init Select a default region us-east-1 : US East (N. Virginia) Select an application to use1)[ Create new Application ] Enter Application Name(default is "rails5app"):Application rails5app has been created. It appears you are using Ruby. Is this correct?(y/n): y Select a platform version. Ruby 2.3 (Puma) Do you want to set up SSH for your instances?(y/n): y Select a keypair. [ Create new KeyPair ](default is 1): 1 That sets up our environment, uses US East(preferable if you want to use AWS free SSL services), Ruby 2.3 and lets you access your EC2 when it is up and running by typing ‘eb ssh’. Now we will create the environment. This is basically how Elastic Beanstalk lets you switch between different versions of your application. Most will use this to set up different rails environments to be deployed(prod, staging, etc) $ git commit -am "Post EB init"$ eb create production ..and wait. Right now Elastic Beanstalk is setting *everything* up for you, loadbalancers, security groups, EC2 server and more. Seriously, you should probably go grab a coffee. Also, I have had the eb-cli log time out on me before, disconnect, but still finish the environment creation. A quick status check afterwards will get you environment information and your ElasticBeanstalk URL for your application: $ eb statusEnvironment details for: productionApplication name: rails5appRegion: us-east-1Deployed Version: app-5cbc-170110_150338Environment ID: e-krea6tdvjxPlatform: 64bit Amazon Linux 2016.09 v2.3.0 running Ruby 2.3 (Puma)Tier: WebServer-StandardCNAME: production.a3rjg2n9mm.us-east-1.elasticbeanstalk.comUpdated: 2017–01–10 22:10:57.815000+00:00Status: ReadyHealth: Green Though, going there now would give you errors. To save you any ulcers, it’s because there is no Rails secret setup. So, here’s how you do that AND add an ENV variable to Elastic Beanstalk instances: $ eb setenv SECRET_KEY_BASE=$(rails secret)INFO: Environment update is starting.INFO: Updating environment production's configuration settings.INFO: Environment health has transitioned from Ok to Info. Configuration update in progress. 1 out of 1 instance completed (running for 51 seconds).INFO: Successfully deployed new configuration to environment. BOOM From here on out, pushing code to your instance(s) is just an ‘eb deploy’ away. Your default rails chariot awaits The rest of the good stuff I bet you’re saying, that’s great and all, but that’s not a production ready app. You’re right, let’s get postgresql, redis and sidekiq going! First up, Postgres. You’ll want to add the ‘pg’ gem to your gemfile and add the following to your database.yml: production:<<: *defaultadapter: postgresqlencoding: unicodedatabase: <%= ENV['RDS_DB_NAME'] %>username: <%= ENV['RDS_USERNAME'] %>password: <%= ENV['RDS_PASSWORD'] %>host: <%= ENV['RDS_HOSTNAME'] %>port: <%= ENV['RDS_PORT'] %> What is all that magic? AWS Elastic Beanstalk will throw those ENV variables on the your ec2 instances as soon as you have an RDS instance setup. Lets do that: Go to https://console.aws.amazon.com/elasticbeanstalk/home?region=us-east-1#/applications Click on the box for your application Click on ‘Configuration’, scroll down to the bottom to ‘Data Tier’ and click ‘Setup RDS instance’ Setup RDS to your liking(postgres, t2.micro(if you want to stay in free tier, username, etc) Wait for AWS to do it’s thing. You may acquire another cup of coffee now. Note: A few readers have brought it to my attention that adding an RDS instance through the EBS interface binds it to the existence or destruction of your EBS environment. Setting up an RDS separately and manually adding the environment variable may have greater RDS assurance for some. Now, another ‘eb deploy’ for your database config should get everything up and running through postgresql. Now, lets add two configuration files most apps will need. First, adding git to the deploy. Add a folder .ebextensions, and a file ruby.config packages:yum:git: [] Now, when you get a few more gems in your app, especially those that insall native extensions, you may get failed deploys from running out of memory. Since, most apps can run on the free tier, and the only time memory is an issue is during a deploy, we will enable swap. Add a file 0001_setup_swap.config in the .ebextensions folder with the following text: commands:000_dd:command: echo “noswap”#dd if=/dev/zero of=/swapfile bs=1M count=3072001_mkswap:command: echo “noswap”#mkswap /swapfile002_swapon:command: echo “noswap”#swapon /swapfile Sweet, we’re almost done. The last piece of almost any production Rails app will be sidekiq(with Redis…which means we can also tie ActionCable into this Redis as well). Let’s start by adding Redis in AWS: Go to : https://console.aws.amazon.com/elasticache/home?region=us-east-1#redis Click create, and fill out the pretty straightforward form(picking t2.micro for free tier again). Click Save and go for a water this time while you wait…three coffees are a lot. Once created, clicking on the instance on the list will take you to a page with an endpoint listed in the table(it should look like your-name.iz6wli.0001.use1.cache.amazonaws.com) Almost done! We just need to add a couple config files for sidekiq, redis and elastic’s deploy! First here is how I like to set up Sidekiq/Redis config: In config/initializers/sidekiq.rb rails_root = Rails.root || File.dirname(__FILE__) + ‘/../..’rails_env = Rails.env || ‘development’redis_config = YAML.load_file(rails_root.to_s + ‘/config/redis.yml’)redis_config.merge! redis_config.fetch(Rails.env, {})redis_config.symbolize_keys!Sidekiq.configure_server do |config|config.redis = { url: “redis://#{redis_config[:host]}:#{redis_config[:port]}/12” }endSidekiq.configure_client do |config|config.redis = { url: “redis://#{redis_config[:host]}:#{redis_config[:port]}/12” }end …and config/redis.yml development:host: ‘localhost’port: ‘6379’test:host: ‘localhost’port: ‘6379’production:host: ‘your-name.iz6wli.0001.use1.cache.amazonaws.com’port: ‘6379’ *optional* config/cable.yml development:adapter: async test:adapter: async production:adapter: redisurl: redis://your-name.iz6wli.0001.use1.cache.amazonaws.com:6379 …lastly, for Elastic Beanstalk .ebextenstions/0002_sidekiq.config( ) gist # Sidekiq interaction and startup scriptcommands:create_post_dir:command: "mkdir -p /opt/elasticbeanstalk/hooks/appdeploy/post"ignoreErrors: truefiles:"/opt/elasticbeanstalk/hooks/appdeploy/post/50_restart_sidekiq.sh":mode: "000755"owner: rootgroup: rootcontent: |#!/usr/bin/env bash. /opt/elasticbeanstalk/support/envvars EB_APP_DEPLOY_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k app_deploy_dir)EB_APP_PID_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k app_pid_dir)EB_APP_USER=$(/opt/elasticbeanstalk/bin/get-config container -k app_user)EB_SCRIPT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k script_dir)EB_SUPPORT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k support_dir) . $EB_SUPPORT_DIR/envvars. $EB_SCRIPT_DIR/use-app-ruby.sh SIDEKIQ_PID=$EB_APP_PID_DIR/sidekiq.pidSIDEKIQ_CONFIG=$EB_APP_DEPLOY_DIR/config/sidekiq.ymlSIDEKIQ_LOG=$EB_APP_DEPLOY_DIR/log/sidekiq.log cd $EB_APP_DEPLOY_DIR if [ -f $SIDEKIQ_PID ]thensu -s /bin/bash -c "kill -TERM `cat $SIDEKIQ_PID`" $EB_APP_USERsu -s /bin/bash -c "rm -rf $SIDEKIQ_PID" $EB_APP_USERfi . /opt/elasticbeanstalk/support/envvars.d/sysenv sleep 10 su -s /bin/bash -c "bundle exec sidekiq \-e $RACK_ENV \-P $SIDEKIQ_PID \-C $SIDEKIQ_CONFIG \-L $SIDEKIQ_LOG \-d" $EB_APP_USER "/opt/elasticbeanstalk/hooks/appdeploy/pre/03_mute_sidekiq.sh":mode: "000755"owner: rootgroup: rootcontent: |#!/usr/bin/env bash. /opt/elasticbeanstalk/support/envvars EB_APP_USER=$(/opt/elasticbeanstalk/bin/get-config container -k app_user)EB_SCRIPT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k script_dir)EB_SUPPORT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k support_dir) . $EB_SUPPORT_DIR/envvars. $EB_SCRIPT_DIR/use-app-ruby.sh SIDEKIQ_PID=$EB_APP_PID_DIR/sidekiq.pidif [ -f $SIDEKIQ_PID ]thensu -s /bin/bash -c "kill -USR1 `cat $SIDEKIQ_PID`" $EB_APP_USERfi One more ‘git commit’ and ‘eb deploy’ and you are good to go. Aw yeah!

Apache

BUNCH

Fetch

How to setup and deploy a Rails 5 app on AWS ElasticBeanstalk with PostgreSQL, Redis and more…

Happy New Year! In this first post of 2017 I wanted to do something fun and a little different, and momentarily switch gears away from RL to generative networks. I have been working with a Generative Adversarial Network called for the past few days, and want to share the fruits of the project. This framework comes from the paper “ ” recently out of Berkeley. Unlike vanilla GANs, which take noise inputs and produce images, Pix2Pix learns to take an image and translate it into another image using an adversarial framework. Examples of this include turning street maps into aerial photography, drawings into photographs, and day photos into night photos. Theoretically, translation is possible between any two images which maintain the same structure. Pix2Pix Image-to-Image Translation with Conditional Adversarial Networks Examples of translated images using Pix2Pix. What struck me as a possible and exciting usage was the capacity to colorize black and white photos, as well as fill in the missing gaps in images. Taken together these two capacities could be used to perform a sort of remastering of films from the 1950s and earlier. Films shot in black and white, and at a 4:3 aspect ratio could particularly benefit from this process. This “remastering” would both colorize and extend the aspect ratio to the more familiar 16:9. Top: input. Middle: My Pix2Pix remaster. Bottom: Original. Taken from . Rear Window In this post I am going to walk through the design of Pix2Pix, provide a implementation, as well as show off some results of the film remastering process. If you are new to GANs, I recommend reading my posts on them in order to get a good sense of how they work. Pix2Pix is really just a GAN plus a few extra architectural changes. Tensorflow two previous _Plus a Tensorflow tutorial for implementing your own GAN_medium.com Generative Adversarial Networks Explained with a Classic Spongebob Squarepants Episode Pix2Pix Pix2Pix builds off of the GAN architecture in a pretty intuitive way. In the GAN formulation we have a generator and discriminator , which are trained adversarially. The generator is trained to generate realistic images from noise input , and the discriminator is trained to differentiate between the real images and those produced by the generator . Using the feedback from the discriminator, the generator can improve its process to produce images more likely to fool the discriminator in the future. Doing so produces more realistic images. _G_ _D_ z x G(x) The most apparent change when going from a GAN to Pix2Pix is that instead of noise the generator is fed an actual image that we want to “translate” into another structurally similar image . Our generator now produces , which we want to become indistinguishable from . _z_ _x_ _y_ _G(x)_ _y_ In addition to the original GAN losses, we also utilize an loss, which is just a pixel-wise absolute value loss on the generated images. In this case, we force the generator to approximate with the additional loss: L1 _G(x) = y_ L1 = |G(x) - y| In a traditional GAN we would never utilize such a loss because it would prevent the generator from producing novel images. In the case of image translation however, we care about accurate image translations rather than novel ones. This desire for accurate images is also why we don’t entirely do away with the GAN aspect of our network. An loss by itself would produce blurry or washed-out images by virtue of attempting to generate images that are “on average” correct. By keeping the GAN losses, we encourage the network to produce crisp images that are visually indistinguishable from the real things. L1 Left: image translation with only L1 loss. Right: Image translation with L1 and GAN losses. Along the lines of ensuring accurate images, the third change to Pix2Pix is the utilization of a U-Net architecture in the generator. Put simply, the U-Net is an auto-encoder in which the outputs from the encoder-half of the network are concatenated with their mirrored counterparts in the decoder-half of the network. By including these skip connections, we prevent the middle of the network from becoming a bottleneck on information flow. U — Net Architecture In the case of Pix2Pix, our input is the image we want to translate and the output is the image we want it to become . By concatenating mirrored layers, we are able to ensure that the structure of the original image gets carried over to the decoder-half of the network directly. When thinking about the task of colorization, the representations learned at each scale of the encoder are extremely useful for the decoder in terms of providing the structure of the colorized image. x G(x) In the Pix2Pix paper, the authors also discuss utilizing a different discriminator architecture referred to as PatchGAN. The idea behind PatchGAN is that instead of producing a single discriminator score for the entire image, a set of separate scores are produced for each patch of the image, and the scores are then averaged together to produce a final score. This approach can improve performance by relying on fewer parameters, and a correctly tuned patch size can lead to improved image quality. A PatchGAN with a patch size the same as the image size is thus equivalent to a traditional discriminator architecture. For the sake of simplicity my Pix2Pix implementation utilizes a traditional discriminator, or PatchGAN over the image. Remastering Films Given the long history of film, many of the classics in the medium were created over half a century ago, and as such were made with very different technology than the films of today. Classics such as Casablanca, Citizen Kane, Metropolis, It’s A Wonderful Life, etc, were all shot in black and white and at a limited aspect ratio. Despite their visual limitations, these films still evoke complex and fully realized worlds. Watching them, it is easy to close your eyes and imagine what they might look like in full color and a wider field of view. Given enough time, an artist could even colorize and extend the frames, as has sometimes been done for classic films. With the power of the Pix2Pix framework, I wondered if it would be possible to have a neural network learn to do this automatically. In order to accomplish this I transformed my GAN implementation into a Pix2Pix architecture as described above and began training it on a set of classic films. The set-up was simple: I decided to utilize a collection of Alfred Hitchcock films ( , , ) as the training set. I choose the films because they were made in color and wide-screen, but were produced at a point where many films were still in black and white. As such, much of the clothing, lighting, and architecture would be similar to the even older films which I wanted to remaster. I also chose them for being some of my favorites from the era. Vertigo Rear Window North by Northwest Each video was resized to 256x144, and image frames were extracted at 2fps. From that point each frame was pre-processed by being converted to grayscale, and cropped to impose a 4:3 aspect ratio. This set of frames composed the training inputs . The original frames were used as the desired outputs . x y Top: input x. Middle: output G(x). Bottom: original y. Taken from . North by Northwest After a day of training, there are impressive results! On the training films themselves the network is able to pretty accurately reproduce the original images (as seen above). Of course in the field of ML this is basically cheating. A separate test set is needed to get a true sense of performance. Below is an example from (another Hitchcock classic) recreated using the network. Critically, the network was never trained using any of these frames, or any other frames from the film. The Birds Left: input x. Middle: output G(x). Right: original y. Taken from . The Birds At least within the transfer domain of “films by the same director” the network seems to perform astonishingly well. Another longer remastered sequence from : The Birds The main reason to create this however was to allow for the remastering of older films for which there exists no color or wide-screen version. Here are some examples of , , and all ‘remastered’ using the trained Pix2Pix network: The Passion of Jean d’Arc Metropolis It’s A Wonderful Life Left: Original. Right: Remastered. Taken from . The Passion of Joan of Arc Left: Original. Right: Remastered. Taken from . Metropolis Left: Original. Right: Remastered. Taken from . It’s a Wonderful Life The results aren’t perfect, but I am pretty happy with them, given the relatively short training time, small training set, as well as minimal changes made to the baseline framework. With a longer training time and a larger set of films used, there is no doubt that results would improve. There are also a number of additions to the architecture that could improve performance. One of the biggest shortcomings is that the network doesn’t take advantage of the temporal structure of the videos. An object off-screen in one frame may be present in another. As such an RNN or sliding window could be utilized in order to capture this information between frames. I leave this work for anyone interested to pick up. This contains everything needed if you’d like to train and run Pix2Pix yourself. Additionally, I have uploaded a pre-trained model , if you’d just like to try remastering your own favorite older film without retraining a model from scratch. Instructions for getting up and running are provided in the repository. Github repository here This kind of work is in the early days still, but I am confident that not so many years from now we will be able to sit down and watch Metropolis or countless other classic films with all the visual detail that we can imagine them having. The capacity to breathe life into older media is an exciting potential of which will only grow as the technology matures. Deep Learning If you’d like to follow my writing on Deep Learning, AI, and Cognitive Science, follow me on Medium @ , or on twitter . Arthur Juliani @awjliani Please consider to help support future tutorials, articles, and implementations. Any contribution is greatly appreciated! donating

Remastering Classic Films in Tensorflow with Pix2Pix

“These are not the exceptions you’re looking for…” As a company dedicated to customer success, it’s important to us that we catch and address issues as fast as we can, ideally customers notice. Writing perfect code is probably impossible, but catching exceptions in our code before they impact customers is something every developer strives for. before Installing an exception tracker is a great first step towards catching problems earlier. However, there’s a big difference between reporting error, and reporting important exceptions. If you’ve ever taken an intro to psychology course, you may have heard about “ ” and “ ”, where psychologists study how the human brain chooses to focus in on certain stimuli when several are occurring at once. Here at , we’ve found that without a finely tuned exception reporting and handling process, we had trouble at times picking out the signal from the noise. every Selective Attention Inattentional Blindness Olark We were logging according to , our real time error tracker. It’s very easy for a startup to get caught up in the hustle and bustle of pushing their platform forward and hand-waving away the long tail errors that may be piling up in the background. With so much stimuli, we found ourselves focusing our attentions elsewhere. 91 events a minute Sentry Fortunately, we knew that the majority of those 91 events a minute did not directly impact our customers, but it was still less than ideal. As developers, we knew we could do better, and make our error tracker become both a useful tool in our debugging process, and a decent marker of code quality in general. We decided to dig deep and see what we could do to redirect our attention back to meaningful exceptions. Here’s what we found: See no exceptions, hear no exceptions, speak no exceptions… We were logging too many errors is a great thing. When we do experience downtime and the same thing is broken for everyone, there really is no need to get hundreds of notifications all reporting the same exception. But if you’re logging so many irrelevant exceptions that you’re constantly getting rate limited, you run the risk of accidentally filtering out unique exceptions. Rate limiting We decided our primary measure for the success of this project would be to reduce the percentage of our rate limited exceptions. We looked at some of our heavy hitters: exceptions that were throwing thousands of times a month. Was something actually wrong? Were we throwing an error appropriately, and if so, why were we throwing them so often? Could we use another method, such as an early return, to escape out of the workflow instead? Ultimately we decided that we throwing errors appropriately. We had several instances like typing the wrong email, or credit card information, where an error was warranted but an exception was not. The trouble was not that we were errors, the problem was that we were these as exceptions. By reducing the volume of exceptions we reported, we made a lot more room for the important ones to rise to the top. were throwing reporting Unexceptional exceptions Fortunately give us a configuration setting to ignore certain exceptions by default. Rather than using a generic “Error” and logging nearly all of them, we started subclassing all of our errors and only logging the ones that we thought we’d most like to know about (server errors for example). Sentry clients We also discovered another potential way to clear out some meaningless exceptions. By default, Sentry installs a global error handler that will catch error in the browser, including ones that have nothing to do with our website — a browser extension exception for example. Sentry allows for the option to ignore exceptions from certain urls or alternatively to whitelist some urls to exclusively listen to. We created an npm package called Lumberjane that contains our ignore settings for all of our frontend applications, which has helped reduce noise. any After successfully ignoring these expected errors, and focusing our attention on real exceptions, our stats started improving very quickly. Soon we were only being rate limited during downtimes, and when we did look at Sentry we actually found new exceptions we hadn’t seen before that shed light on issues we were already investigating. Missing contexts Investigating an exception from a few weeks ago can be tricky. We usually deploy code multiple times everyday. Unless you’re very familiar with a particular error, if you’re more than a few days out from a deploy, it’ll take some serious digging to figure out which deploy was the source of the bug. This is fortunately an easy fix, as will tag each exception with a git commit. Sentry’s releases feature We also weren’t taking full advantage of the fact that Sentry allows exceptions to be tagged with additional context, a user id or email for example. By ensuring that we attach these sorts of pertinent details it’s easier to see how many and what kinds of customers are affected by a given exception, and better yet, allows us to directly follow up with customers if we notice anything concerning. Sometimes the context for an exception was unreadable Even when we knew an issue was occurring, our frontend developers often found themselves staring blankly at minified code. Minifying code is great for loading apps quickly, but nearly impossible for human eyes to look at. What’s more, on our staging environments our frontend exceptions were even more cryptic, as Sentry did not have access to our VPN protected files. All we had to go on was that an exception occurred somewhere in a giant concatenated javascript file. Fortunately, Sentry allows us to to their servers directly. Through that process we can see the relevant files as part of the stack trace, exactly as they were when we wrote the code, unminified, and before they were transpiled from ES6 or Coffeescript. upload sourcemaps We hadn’t defined a clear strategy for prioritizing low-severity exceptions Last but not least was the issue of process. While high severity exceptions are easy to justify taking time from projects to work on, as a team we didn’t always know what to make of the low severity bugs. While Olark as a company puts a high level of trust in engineers to work on what they think is important, as an engineer it’s not always easy to know how much effort to put on low severity bugs. I find with hard decisions, my default tends to be to postpone. Small bugs that we knock out in a few hours would just sit there in the queue, with the queue becoming more and more daunting to look at. could We’re still testing out what process works best for us as a team and for the company as a whole. One idea we’re trying out is to assign each developer one bug a week to investigate in addition to their regular work. It’s the amount that we might do on our own anyway, but in this way it’s a formalized process and serves as both permission and encouragement to focus on the small potatoes. By identifying these issues and researching best practices for dealing with them, we’ve gone from 91 events a minute down to 1–3 events a minute, from nearly always being rate-limited by Sentry, to only getting rate-limited during actual downtimes. We can definitely still make improvements, and we’re still learning, but we’ve come a long way in creating an infrastructure and process which will support engineers in building high quality code, which hopefully translates into an easier, smoother experience for our customers. is a Callback Handler at Olark. She lives in New York and enjoys SciFi, long hikes through the city, and volunteering to make the New York City tech scene more awesome. About the Author: Sarah Zinger Want to read more articles like this? _If you've done any sort of front-end engineering work over the past few years you've more than likely been inundated by…_blog.olark.com How a SaaS company evolves its front-end tech stack _Our friend, Matthew Harris is the founder of sendwithus. He recently wrote an article for Venturebeat about social…_blog.olark.com Effective Olark API Use: Guarding against social engineering attacks

HackerNoon Tech Stories Archive January 10th, 2017

How I Decided My Idea Was Worth Pursuing (I’ve Had A Lot Of ‘Ideas’)

@peter.e.schroeder
Peter Schroeder 🚀

A Quick 7-Step Guide for Naming Your Next App or Startup

@gmcconnaughey
Grant McConnaughey

What does it mean to “code?”

@richardeng
Richard Kenneth Eng

It’s robots all the way down

@codevalley42
codevalley

Completed != Validated

@johnpcutler
John Cutler

What the Trello Acquisition Means For Atlassian

@benfwirtz
Benjamin F. Wirtz

Intimate behind-the-scenes footage from the Yahoo renaming meeting

@jokejokecry
Joke Joke Cry

What are you optimising for?

@fredrivett
Fred Rivett

Reorganising a directory structure to solve “Cannot find module/preset/plugin” in grunt with babel…

@christianchown
Christian Chown

Six tenets of tech for good

@wearecast
CAST

Why Our Desire For Legitimacy Holds Us Back From Pursuing Our Creative Calling

@poornima
Poornima Vijayashanker

Video Conferencing without the Video?

@chris_82106
Chris Ward

Single vs multi-tenant SAAS

@rymohr
Ryan Mohr

How to setup and deploy a Rails 5 app on AWS ElasticBeanstalk with PostgreSQL, Redis and more…

@rob__race
Rob Race

Remastering Classic Films in Tensorflow with Pix2Pix

@awjuliani
Arthur Juliani

Keeping Exceptions Exceptional — How we learned to filter meaningful exceptions

@OlarkLiveChat
Olark

HackerNoon Tech Stories Archive January 10th, 2017

@peter.e.schroederPeter Schroeder 🚀

@gmcconnaugheyGrant McConnaughey

@richardengRichard Kenneth Eng

@codevalley42codevalley

@johnpcutlerJohn Cutler

@benfwirtzBenjamin F. Wirtz

@jokejokecryJoke Joke Cry

@fredrivettFred Rivett

@christianchownChristian Chown

@wearecastCAST

@poornimaPoornima Vijayashanker

@chris_82106Chris Ward

@rymohrRyan Mohr

@rob__raceRob Race

@awjulianiArthur Juliani

@OlarkLiveChatOlark