I’ve read this article, by Matt Burrough, on how the clipboard works on windows.
Explains how the API works and how the different formats and priorities are organized so the new application can decide which format to accept.
Tags: windows, clipboard, matt-burrough, format, copy-paste
I’ve read this article by Belen Albeza on how top coders don’t need to spend all their time programming or with activities related to programming.
Explains some techniques to make the most of the working hours and some strategies to balance your work-non-work life.
Tags: belen-albeza, coding, time-management, energy-management, improvement, opinion, work-life-balance
I’ve read this article by David Pierce on how the phone device is vulnerable and what options we have available to make it a secure computing device.
Either switch to a branded-as-secure phone or stick to the main options (Android, iPhone) plus activate some options (updates to the apps and operating system), stay away from public hotspots, don’t lend it to strangers and use some apps to monitor what resources apps are using
Tags: david-pierce, security, phone, mobile-device, hotspot, iphone, android, ios
I’ve read this article by Chantal Panozzo comparing the way of living and the economic standards in Switzerland and the US.
Mainly about the topics of the social security network, provided by the state, taxes and owning a car
Tags: chantal-panozzo, comparison, way-of-living, living-standard, car, social-security, usa, us, switzerland, economy
I’ve read this article by Chip Heath on a technique to make hard decisions: the 10/10/10 rule; How would you feel 10 minutes, 10 months and 10 years after having applied the actions from that decisions?
Tags: decision, decision-making, rule, ten-ten-ten-rule, chip-heath
I’ve read this article by Danielle Kurtzleben on how to retire early or achieve financial independence early in your career: save a big percentage of your salary, invest wisely and reduce costs.
Tags: danielle-kurtzleben, investment, frugality, early-retirement, retirement, financial-independence, independence, finance, value, core-value
It is a good practice to push your local work at the end of the day. Be it for increasing the bus factor (more people have the code), be it for reducing the lifespan of the branches (less time without integrating) or just enabling visibility (your teammates to see what has been developed). If you’re using Continuous Integration (CI) or Continuous Delivery (CD), this is even more often
You can even do it more often: for example before going to lunch, before a meeting, before a demo, etc.
Working with many repositories (e.g. a microservices environment/architecture), it is often the case where you will have multiple folders with work, possibly work in progress (WIP).
This is why we have created a small tool to detect git repositories that have local changes that haven’t been pushed yet: Find WIP
Feedback is more than welcome.
I’ve read this article by Marko Karppinen that explains how a mistake in understanding the pricing model of AWS Glacier cost 150$ instead of the expected 0.86$
When cloud providers use uncommon and/or unpredictable pricing models, even your informed hunch about the cost can be off by several orders of magnitude, like the price differential between an iPad and a Ferrari.
The only way to avoid this is by reading, very carefully, through the laughably long passages of meandering technical trivia that constitute the Glacier FAQ or, indeed, this Medium post.
Tags: quote, glacier, amazon, aws, amazon-web-service, marko-karppinen
I’ve read the release notes for Debian 9 “Stretch”. By the Debian team
Tags: debian, release-note, stretch, linux, distribution, distro
I’ve read this article by Amir Salihefendic on why they have created a tool for online async communication, where the online presence icon is disabled and communications happen around threads.
Trying to transform the online (from real-time to async) communications to leave spaces for deep work.
Tags: amir-salihefendic, deep-work, todoist, doist, twist, app, slack, online-communication, communication, productivity, async, real-time, work, chat
I’ve read this article by Chris Dixon that explains what is a crypto currency, what is a smart contract and how this can revolutionize the market.
Also explains public vs private networks and tokens
Tags: chris-dixon, public-network, private-network, token, ethereum, bitcoin, cryptocurrency, contract, smart-contract, miner, mining, comparison
I’ve read this article comparing the Reagent vs React (clojurescript vs javascript), going into details for both technologies. By Inge Solvoll
Conclusion: Code vs Data
Hopefully I managed to show you a few things that Reagent brings to the table:
- Concise and compact
- Creating functional style components is super easy
- Immutable data is the default
- But the thing that fundamentally separates it from React/JSX is the data focus.
JSX creates instructions: React.createElement(‘div’).
Reagent creates data structures: [:div].
The former is opaque, hard to inspect at runtime. The latter is highly transparent, and easily inspectable in more than one way.
Your app is declared using nothing but pure data, using nothing but plain functions to manipulate the data. The very rich Clojure standard library with functions like map, filter and reduce at your disposal, without any funky new syntax to learn.
Tags: clojurescript, comparison, javascript, react, reagent, om, cljs, js, inge-solvoll
I’ve read this article by on the security of Philips Hue lightbulbs, a kind of IoT device that has been hacked using a defect in their protocols
Tags: adrian-colyer, zigbee, philips, hue, philips-hue, iot, defect, hack, security
I’ve read this article by James Forshaw, in which they explain how the Chrome browser does not use the Win32k system calls (under certain conditions), to reduce the attack surface
Tags: attack-surface, rasq, security, chrome, chromium, project-zero, win32k, win32, windows, google, flash, ppapi, james-forshaw
I’ve read this article by Christian Kellner about a common way of operating with a program’s Language Server Protocol (LSP) so all languages could benefit from standard tools. Then, a new editor would just have to implement the bindings to LSP to support those.
Similar to what LLVM is to some languages: once you specify your syntax in terms of LLVM, you can benefit from the improvements that LLVM provides.
Tags: christian-kellner, lsp, emacs, rust, ast, analogy
I’ve read this article by Saku Panditharatne on how she has created a massively open online course (MOOC).
Tags: saku-panditharatne, mooc, passive-income, business, side-project, side-business
The Nature of Software development: reading breadcrumbs, quotes, thoughts
Preface
The Natural Way serves end users well because it delivers value to them sooner.
serves the business […] because it provides important information quickly, and because it provides the ability to adjust direction as needed.
serves management […] see what’s really going on inside the project so that when action is needed, there will be time to act. And it reduces management’s problems by making information visible […]
[…] easier for developers. […] clear direction and allows them freedom to use their skills to build what the organization needs, when it’s needed.
(p. xv)
Part I: The Circle of Value
Chapter 1: The search for value
Value. “what you want.”
(p. 5)
On the building blocks of value or to produce value:
Guiding. We produce value by creating teams with responsibility for creating value.
(p. 5)
The value in guiding is not related to creating value in itself, but to help others so they can create value.
Therefore, the value of guiding depends on the value of the value-producing people
Organizing […] We organize around features, because features give us the ability to plan and build value most rapidly
(p. 5)
Planning […] selecting the features we need, in the order we need them.
(p. 5)
Building […] product feature by feature
(p. 5)
Slicing […] smallest possible value-bearing size
(p. 5)
Quality […] always has a good design and that it is as nearly defect-free as possible
(p. 5)
Chapter 2: Value is What we Want
we generally get value by delivering features. Features that have value. Features that we want.
(p. 7)
software can save time or money. Software can help us earn money
(p. 7)
I think of value as simply what we want […] Each choice gives us something we value
(p. 7)
A project delivers value only when we ship the software and put it to use
(p. 8)
Since most users don’t use all the features, a smaller set of features can provide real value, and provide it sooner.
(p. 10)
pieces that make sense to us, and to our users. […] minimal marketable features (MMFs)
(p. 12)
Chapter 3: Guiding Goes Better “Feature by Feature”
With a monolithic project, late in the game we can’t do much to cut costs. We have already written requirements for things we’ll never get
(p. 22)
We laid out this project with an all-or-nothing mentality.
(p. 22)
When our projects grow feature by feature, we can respond to what’s really happening. We can respond to the changing needs and inputs of the business and of management.
(p. 24)
Chapter 4: Organizing by Feature
To get the work done, different parts require different skills. The work won’t be done […] until it has had the attention of people with each needed skill.
If we organize teams by skill-set, each piece of work will need to be passed around among teams
(p. 26)
organize into small teams, each of which builds features that the Product Champions can understand. Make sure that each team has all the people and all the skills necessary to build the entire feature, not just part of it
(p. 27)
[…] we can allocate work across teams easily […] Responsibility and authority are aligned.
(p. 27)
the people belong to the feature teams.
(p. 30)
You belong to your family; you’re a member of the golf club
(p. 30)
A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.
(p. 30)
Chapter 5: Planning Feature by Feature
Vision is about big ideas, not tiny bites.
(p. 32)
General Eisenhower said, “Plans are useless, but planning is indispensable.”
(p. 33)
We do need to plan. We don’t need a detailed list of what will happen and when
(p. 33)
[…] software people are terrible at estimating, because humans are terrible at estimating.
(p. 34)
set a time and money budget; produce the most valuable features first; keep the product ready to ship at any time
(p. 34)
It’s not good enough to plan just at the beginning
(p. 36)
I don’t recommend working with larger stories and breaking them down into technical items, often called tasks
(p. 36)
Stick with stories
(p. 36)
[…] break down stories into smaller stories, each making sense to the business-side people.
(p. 36)
the team itself should decide how much work it can accomplish in the next two-week interval
(p. 37)
The point isn’t to make good estimates—the point is to do good work at a consistent pace.
(p. 37)
There are some serious risks to estimates: we have an almost irresistible desire to “improve” them, or to compare them. […] business and management get the best results by selecting the work to be done and the work to be deferred
(p. 38)
Is prediction better than steering?
(p. 38)
Planning with “stretch goals” is destructive.
[…]
Hurrying, they’ll inject more defects. Since defects take longer to fix than they do to prevent, hurrying will slow you down. […]
[…]
Dirty code slows you down as well […]
Pressure is destructive. Avoid it.
(p. 39)
[…] estimates are likely to be wrong, and they focus our attention on the cost of things rather than on value.
(p. 40)
Chapter 6: Building the Product, Feature by Feature
We need to sharpen our vision of what the product must do—and what’s just “nice to have.”
(p. 45)
To be sure we’re free of defects, we need to check everything, all the time […]
(p. 48)
[…] grow the design as we go. If we design too much, we won’t get as many features, and that will show up. If we design too little, features will be hard to do, we’ll slow down
(p. 49)
Chapter 7: Build Features and Foundation in Parallel
Each feature needs a solid foundation of design, a solid “infrastructure.”
(p.52)
We need to do as little work as possible to deliver the best possible product by our delivery date…and we need to do that work as soundly as we can afford.
(p. 53)
Developers are often trained to try to design a system up front
(p. 59)
Chapter 8: Bug-Free and Well Designed
Our product is made up of a growing set of correctly working features, built on a growing, evolving foundation of design.
(p. 61)
Defects amount to negative features. Progress is uncertain. Eliminate defects to provide clarity on what’s done.
We’re trying to plan by features, grow by features, and manage by features
We cannot work effectively in a world of defects.
(p. 62)
At the end of every iteration, we need to have the software as close to defect-free as possible. The only way to get there is to test it.
We test at two levels, with “Business” tests and “Programmer” tests.
(p. 65)
If we don’t check something, we don’t know whether it works
(p. 66)
We need to have a good design at all times. A bad design slows us down, because it is hard to change […] We need a high-quality design at every moment.
(p. 71)
Chapter 9: Full Circle
-
Value is what we want. Features deliver value. Delivering features early gives us value sooner.
-
Managing by looking at value works better than managing by dates or artifacts that don’t deliver value.
-
Planning features is easy enough to do. Estimate if you must. Selecting the work based on Yesterday’s Weather works better.
-
Building by features requires us to build a small, complete product, every couple of weeks. That product must always work correctly, and it must always be well designed.
-
Development must deliver real working features. The product must be well tested. Business-side people and developers contribute to testing. The product must be well designed. Developers keep the design alive all the time.
[…] A commitment from the top of the business, down to the individual managers and developers […]
(p. 77)
A quote from the book The Nature of Software Development by Ron Jeffries, talking about value (in software) and the building blocks to achieve it:
Value. Value, we’ll see, is “what you want.” […]
We’ll tell the story by building up from the bottom of the pyramid, describing how to guide, organize, plan, and build our product, in small slices, with a focus on quality. The value we produce is based on these.
Guiding. We produce value by creating teams with responsibility for creating value. We make sure they understand what is needed, and understand the time available. We guide them by observing what they actually build.
Organizing. We organize teams with the ability to get the job done. We organize around features, because features give us the ability to plan and build value most rapidly. We apply good people and help them build their skills.
Planning. We steer our projects by selecting the features we need, in the order we need them. We produce value in a timely fashion.
Building. We build up our product feature by feature. This provides frequent delivery of value. We can see how things are progressing early and often.
Slicing. We slice features down to the smallest possible value-bearing size. We build a capable product as early as possible, and then enhance and grow it as the deadline approaches. We’re always ready to ship.
Quality. We apply the necessary practices to ensure that our product always has a good design and that it is as nearly defect-free as possible. We’re able to build value continuously, sustainably, indefinitely.
(p. 5)
I’ve read this article by Rick Branson on the history of UUID.
Describes the history of uid, uuid, early computing (both networked and not networked) and their own implementation of a uuid library
Tags: uuid, uid, flake, snowflake, ksuid, go, golang, rick-branson, library, implementation-history
I’ve read this article about how cloudflare manages its logs. By Hunter Blanks
Tags: log, cloudflare, comparison, what-worked, what-did-not-work, kafka, citusdb, sre, site-reliability-engineering, analytics, hunter-blanks
I’ve read this article that describes how important is to say no to some ideas or projects so you can say yes to others.
In other words, how prioritizing is important as time and energy (i.e., resources) are not infinite and must be allocated accordingly
Tags: diana-kander, hbr, harvard-business-review, priority, energy, resources, time, pet-project, yes-people, no-people, yes-culture, no-culture
I’ve read this article about how technology can be seen as toys before it is developed to the point where it can be expanded and used for other purposes than the one expected / designed for. By Benedict Evans.
Tags: benedict-evans, technology, prediction, usage, invention, philosophy, wolfgang-pauli
I’ve read this article comparing Option and Optional as types that can contain a value, but maybe not. By Michał Chmielarz
Tags: michal-chmielarz, option, optional, vavr, javaslang, comparison
I’ve read this article by Dan Luu comparing the use of the mouse and the use of the keyboard and their speeds.
He groups existing literature on the topic plus some experiments he has done himself.
Mentions the amount of myths related to this, based on old and non-accurate research.
Tags: dan-luu, keyboard, comparison, mouse, human-interaction-device, hid, interaction, user-experience, interface
I’ve read this article by Timothy C. May forecasting the development of a new market based on cryptography and secure communications.
The same that barbed wire transformed property in the West, is the analogy he uses
Tags: timothy-may, anarchy, encryption, market, forecast, crypto-anarchism, public-key-encryption, zero-knowledge-proof, cryptography