Programming – Page 4 – Software and Other Shenanigans

Are you shipping usable components?

General Commentary, Programming No Responses »

Aug 312019

One of the benefits of using Javascript frameworks like React or Vue is that you can build and export your own custom components. This lets other teams in your organization or even external developers build front-ends that have a consistent look and feel across the board as well as follow any style or branding guide you have. That’s great, but think about the components you’re putting out there for developers to use. Are you putting out the bare minimum or are you shipping front-end tools that speed development up and make people’s lives easier (you know, the whole point of shipping front-end components like this)?

The trouble with Redux

Programming No Responses »

Jul 312019

Do any research into current front-end development, and you’ll hit React pretty quickly. As far as modern Javascript frameworks go, React is probably the standard Javascript framework used by startups and other companies that haven’t already heavily invested in another front-end framework. While React does a decent job of packaging up HTML and Javascript into reusable components, there’s been some design decisions around handling application state in React, namely by using a framework called Redux, that make developing applications harder than it has to be, and make it worth your while to look for other options before you start falling into its rabbit hole too.

Is there a future for Java?

General Commentary, Java, Programming No Responses »

Apr 302019

I’ve been developing in Java since late 2009. It’s a good language, but I’m starting to wonder what kind of future it has. I’ve been using Java 8 since shortly after it came out, even though Java is currently on version 11. Java’s obviously still being developed, so why not move forward? A big part isn’t the infamous module system that launched in Java 9, and broke a lot of stuff. Part of it is the fact that Java is owned and controlled a by a company that seems more interested in rent-seeking off oa Java than doing anything innovative with it.

Software should have a strong opinion

General Commentary, Programming No Responses »

Mar 312019

Software is written to solve a problem. Sometimes, it’s more than one problem, but you get the idea. Being someone who both uses and writes software, I’ve found the best software out there doesn’t just solve a problem, but was written with a clear and definitive opinion about how that problem should be solved. That’s not by accident or coincidence, it’s very much causal.

Tuning your code

Programming No Responses »

Oct 312018

I got a comment on my post about performance tuning a REST API call asking about code tuning with examples. I don’t have code examples handy, but I can certainly run through some general performance tuning tips I’ve found over the years. No matter where you find advice about improving your code’s performance, keep in mind that every situation is different, and those differences could impact the relevance and usefulness of any advice offered.

Minimum viable products – the most difficult products to build

General Commentary, Programming No Responses »

Mar 262018

Probably 1 of the most difficult juggling acts in software development is scoping a minimum viable product. I’m pretty sure a lot of that comes from the juggling act and judgement calls that constitute defining said minimum viable product. It’s not easy to do, mostly because defining a minimum viable product involves balancing 2 mutually exclusive terms. That said, I think you can find the best set of tradeoffs en route to the minimum viable product by examining the principles behind each part and then combining them back together once we understand what we’re looking for to satisfy each keyword.

A few thoughts on unit tests

General Commentary, Programming No Responses »

Sep 292017

Automatic software testing is an interesting thing. Books have been written on the topic, libraries have been built to try to bring the practice to traditionally hard-to-automate sections of testing, and in some places, it’s so important it’s the first code that gets written. There’s a lot of different philosophies about how it should work, but in my experience, it’s probably an area where the less religious you are about it, the better it’s likely to work for you.

parallelStream() at your own risk

Java, Programming, Work No Responses »

Jun 262017

Java 8 introduced a lot of cool features, 1 of the most useful of which was the stream() method. This nifty little method lets you treat an Iterable as a stream, enabling cool things like lambdas operating over a list. Related to stream() is parallelStream(). This lets you group your stream into smaller streams that are run in, you guessed it, parallel. Specifically, your data is processed in a thread pool the size of the number of cores on your machine, minus the one running your app. That’s a handy piece of information you’re going to want to keep in mind before you start throwing this nifty little call around in your code. Continue reading »

Keeping a ledger on technical debt

General Commentary, Programming No Responses »

Feb 052017

Software development is all about making tradeoffs. Sometimes, we do stuff because it’s quicker and get things out of the door faster, not because it’s the best option long-term. Do software development long enough, and you’ll learn the term “technical debt” – which is formally defined on Wikipedia as “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. A more informal, but probably just as accurate definition could also be “the price(s) you’re paying now to have shipped things earlier.” Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off when there’s no other alternative.

Debugging a performance bottleneck

Java, Programming, Work No Responses »

Sep 302016

Recently, we had a Kinesis consumer back up due to a deployment problem. Sadly, this problem went on for 2 days without us noticing, so we were pretty backed up. Now in theory, we should have been able to catch back up to real-time data sometime later that calendar day. In reality, we fell 2 days behind and it took us 2 days to catch up. That’s not acceptable, and I wanted to document the list of things we tried and how well they worked and to document our process for looking for the bottleneck. Obviously, there’s tons of room for improvement in the code, but there’s also a lot of room for improvement in how we were doing things before, and probably a lot of room for in how we went about trying to fix the issue.

Older Entries Newer Entries