Programming Flutter, in beta


This post is by Pragmatic Bookshelf from Pragmatic Bookshelf


Click here to view on the original site: Original Post




Full Stack


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




From transistors to typography.  From silicon to selectors.  From Layer 1 to Layer 7 of the <a href="https://en.wikipedia.org/wiki/OSI_model">OSI model</a>. The <em>full</em> stack in Full Stack is big, <em>really</em> big.  You&#39;ve got to know a lot to create a website from <em>scratch</em>.

If you wish to make an apple pie from scratch, you must first invent the universe.

— Carl Sagan

The individual that can mine the rare earth minerals, design the chip, code an operating system, connect it to an outside network, code some server software and also design human facing interface matching our 2019 standards; that person doesn't exist. You aren't that person. No one can do that, just like in the 1950s no one cut down trees, made paper from pulp, created a camera, took great photos and wrote great content for a world-class magazine. The number of things humans must do and do well to get information to Continue reading “Full Stack”

Open Source Time at Hashrocket


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




It&#39;s Friday afternoon, my brain cells are fried, my stomach is full and it&#39;s time for Hashrocket&#39;s most cherished employment perk. That time when we can open  whatever editor, on whatever operating system, on whatever computer, with whatever keyboard and work on whatever we want. Open source time. 

We call it open source time, but don't get it twisted, it's not time to work on open source software, but instead it's the time itself which is open sourced. You can source it any way you want, openly. And no, I'm not really sure what that means. All I know is that my mind is free to stretch. I can crack open the code to Phoenix, I can write a weird blog post and I can scratch that programmer itch that's been itching ever since I found out about useMemo on Monday. That combined with an itch to make colorful squares Continue reading “Open Source Time at Hashrocket”

Programming Elm, in print; July PragPub Magazine now available


This post is by Pragmatic Bookshelf from Pragmatic Bookshelf


Click here to view on the original site: Original Post




Practical Microservices, in beta


This post is by Pragmatic Bookshelf from Pragmatic Bookshelf


Click here to view on the original site: Original Post




Technical Blogging, Second Edition, in print


This post is by Pragmatic Bookshelf from Pragmatic Bookshelf


Click here to view on the original site: Original Post




Technical Blogging, Second Edition


This post is by Pragmatic Bookshelf from Pragmatic Bookshelf


Click here to view on the original site: Original Post




Pest Control: How We Manage Bugs


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




There is no such thing as bug-free code. Even code that was functional on delivery can <a href="https://en.wikipedia.org/wiki/Software_rot">develop issues over time</a>. Part of owning and maintaining software is always being prepared to address bugs. We often work with clients who are new to software development, so how to test for and report bugs is a perennial topic. Here’s how we like to work with stakeholders to catch and resolve issues. 

The Value of a Detailed Bug Report

If you are reporting a bug, the most important thing to be able to do is explain how to reproduce the issue. Often, the majority of the time that a developer spends on resolving a bug is spent just trying to replicate it. Once an issue can be reproduced, then the developer can track down causes and test fixes. Giving the developer as much information as possible up-front in a detailed bug report can Continue reading “Pest Control: How We Manage Bugs”

Pest Control: How We Manage Bugs


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




There is no such thing as bug-free code. Even code that was functional on delivery can <a href="https://en.wikipedia.org/wiki/Software_rot">develop issues over time</a>. Part of owning and maintaining software is always being prepared to address bugs. We often work with clients who are new to software development, so how to test for and report bugs is a perennial topic. Here’s how we like to work with stakeholders to catch and resolve issues. 

The Value of a Detailed Bug Report

If you are reporting a bug, the most important thing to be able to do is explain how to reproduce the issue. Often, the majority of the time that a developer spends on resolving a bug is spent just trying to replicate it. Once an issue can be reproduced, then the developer can track down causes and test fixes. Giving the developer as much information as possible up-front in a detailed bug report can Continue reading “Pest Control: How We Manage Bugs”

Incident Report: Like Attack


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




On May 13th, til.hashrocket.com (TIL) experienced an attack. This attack had the effect of overstating the relative amount of affection that the users of TIL felt towards the posts on the front page of TIL. While most of our developers will bask in the glow of any and all affection, either automated or not, the unanticipated scale of affection combined with the notifications that our slack channel receives on relatively small increments of &quot;likes&quot; both chafed at our sense of truth and also served as a Denial of Chat (DOC) attack in our main chat channel. The root cause of this attack was a script making requests from a computer in Dearborn, Michigan written by an author who had discovered that there is no limit to the amount of liking that can be expressed on TIL through clicking and post requests.

Timeframe

Web Development with Clojure in beta, Build Chatbot Interactions in print


This post is by Pragmatic Bookshelf from Pragmatic Bookshelf


Click here to view on the original site: Original Post




Big Reasons to Write Small User Stories


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




In software development, before any code can be written, you begin by gathering requirements. The clearer the requirements, the better the code reflecting those requirements will be. Writing quality user stories is an important first step towards setting development up for success. What is one way to make sure that the user stories are good? Make them small. 

Why should you write small user stories?


1. They are easier to discuss and understand

Small stories are easier to talk about and get your head around. A large story has room for vagueness. You either risk making wrong assumptions or you spend time coming back for clarification again and again. A small story lets you have focused discussion around the specifics of a single behavior.

2. They are easier to test and accept

It is easier to write a test for a small story than a big story. Testing a single Continue reading “Big Reasons to Write Small User Stories”

Small, Sharp Software Tools, in print


This post is by from Pragmatic Bookshelf


Click here to view on the original site: Original Post




Technical Debt Part 2: Management Strategies


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




Just like good financial planning involves a strategy for paying off credit card debt or budgeting for home maintenance, good project planning involves setting a strategy to avoid and reduce technical debt. This post discusses methods to manage technical debt.

This is the second part of a two-part series. Visit the first part for an introduction to technical debt, its similarity to personal finance, and how it slows down development.

Why you should manage your technical debt load

Your bank isn’t going to give you a contract for a credit card or a home repair loan without some strict rules about how they will be paid back. To keep technical debt from piling up, slowing you down, and costing you precious time, you need to develop your own system of accountability to manage debt.

First, avoid taking on debt that you don’t need. Using the credit card analogy, what are Continue reading “Technical Debt Part 2: Management Strategies”

iOS Unit Testing by Example


This post is by from Pragmatic Bookshelf


Click here to view on the original site: Original Post




#EmberJS2019 More Accessible Than Ever


This post is by Yehuda Katz from Katz Got Your Tongue


Click here to view on the original site: Original Post




It’s that time of year again: time to think about what the next year of Ember should hold.

Personally, I feel really great about the community’s effort around the Octane edition. What’s great about Octane, and any future edition we do, is that it’s a focus on polishing and documenting the features, and providing a clear transitional path from where we were to where we’re going.

Octane includes a lot of stuff we’ve been working on for a long time. Some highlights:

  • jQuery is no longer included by default in new apps
  • Glimmer components are the default components in Octane, which includes a new, massively slimmed down base class and angle bracket invocation.
  • Element modifiers are a new, more composable way to interact with the DOM from components.
  • Tracked Properties are the default way of managing data flow in Octane, which eliminates the need for a special computed property feature.

    Continue reading “#EmberJS2019 More Accessible Than Ever”

Technical Debt Part 1: Understanding Debt


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




One of the biggest challenges around technical debt in software development is how to communicate its true costs to stakeholders and decision-makers. The first part of this two-part series on technical debt explores some ways it can be helpful to think of technical debt like financial debt.

What is Technical Debt?

Technical debt is a term to describe the shortcomings of existing code that could be changed to perform better, and the ongoing consequences for failing to address it.

There are two ways to generate technical debt: actively and passively.

Technical debt is incurred actively when development has taken a shortcut. Maybe it was a hack solution or skipped a step to build a feature faster, but now the code is hard to extend or unsuitable for long-term performance. Sometimes, a shortcut is a conscious choice to get something done sooner. Other times it’s an unanticipated consequence of not having Continue reading “Technical Debt Part 1: Understanding Debt”

From Chaos to Successful Distributed Agile Teams


This post is by from Pragmatic Bookshelf


Click here to view on the original site: Original Post




Extracting programmer employment data from BLS


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




This is the description of a technical journey to better understand the labor market for computer programmers by using numbers from the Bureau of Labor Statistics. As a government agency, I expected the BLS to provide a readily available, significant amount of raw historical data, and while true, this data is provided in a number of ways each of which is unsatisfying in its own way. The BLS has an api, a large cache of public flat files, and a set of spreadsheets for each year dating back to 1997. In this blog post I explore each of these methods of extracting data from BLS.

The growth of the labor market for Computer Programmers

As a consultant that gets to experience a number of different project environments either through my own experiences or the experiences of my co-workers, I'm interested in how the rate of growth in the industry affects Continue reading “Extracting programmer employment data from BLS”

2000 Today I Learned posts


This post is by Hashrocket from Hashrocket


Click here to view on the original site: Original Post




2000 TILs is a landmark but is just a small window into what we do at Hashrocket every day.

Two Thousand

This week, we published the 2000th post to our daily learning site, Today I Learned. The statistics page gives a sense of the scope and scale of this ever-evolving project. It is the result of continual small contributions by the entire Hashrocket team.

Two thousand TILs began on April 13th, 2015. Springtime: a great time of year to begin something new. We've averaged a bit under two posts a day since starting to document these things in a digital, shareable way. Of course, before we had TIL as a platform there was a fair amount of non-shareable, non-documented learning. Okay, a "fair amount" is an understatement; Hashrocket's entire history has been about teaching and learning and craftsmanship and sharing. You can't be a great developer without obsessing over all Continue reading “2000 Today I Learned posts”