jammycakes

9 ms·

1.
by jammycakes 3y ago
That's a good approach if you can cleanly separate out the old code from the new code, and if you can make sure that you've got all the old functionality behind the switch. Unfortunately this can be difficult at times. Feature tog
2.
by jammycakes 3y ago
This incident highlights a problem that is often overlooked in the debate about feature branches versus feature toggles. I've worked with both feature branches and feature toggles, and while long lived feature branches can be painful t
3.
by jammycakes 3y ago
It isn't in practice. Only a minority of methods actually need it. It's certainly far, far better than having to add exactly the same check after every method call. Which is only what you need to do if you're working in a sit
4.
by jammycakes 3y ago
Usually, no you don't. You only write a try ... catch or try ... finally block round the entire method body, from the point where you create the resources you may need to clean up to the point where you no longer need them. For example
5.
by jammycakes 3y ago
You clean up processing that your own method is responsible for. For example, rolling back transactions that it has started, deleting temporary files that it has created, closing handles that it has opened, and so on and so forth. You rarel
6.
by jammycakes 3y ago
> External services having gone offline, timeouts, and invalid user input are expected conditions you should handle locally. Not necessarily. You should only handle expected conditions locally if there is a specific action that you need
7.
by jammycakes 3y ago
> No; you simply abstract the underlying subsystem’s exceptions in your own types, the same way you do with any other type. That's all very well as long as people actually do that. It doesn't always happen in practice. And even
8.
by jammycakes 3y ago
If you want to (and are able to) document all possible failure modes, then checked exceptions will give you that. As far as I can tell, railway oriented approaches can't. Unfortunately, you can only do that when the number of possible
9.
by jammycakes 3y ago
Missing dependencies. External services having gone offline. Timeouts. Foreign key violations. Data corruption. Invalid user input. Incorrect assumptions about how a third party library works. Incorrectly configured firewalls. Bugs in your
10.
by jammycakes 3y ago
> The unfortunately missing part of exceptions (in mainstream languages) is that they handle this invisibly. Figuring out, at compile time, what sort of exceptions can appear inside a given function is not obvious. Figuring out, at compi
11.
by jammycakes 3y ago
The author followed up this post with another one a few years later titled "Against Railway Oriented Programming": https://fsharpforfunandprofit.com/posts/against-railway-orie... Railway-oriented programming
12.
by jammycakes 4y ago
> I think a much better pattern would be to enable dev teams to self serve. Set up the required infrastructure and guard rails, then let teams handle their own deployments and infrastructure. I think that's how DevOps is actually su
13.
by jammycakes 4y ago
In a previous job, I joined a team that was supposed to be introducing DevOps to the organisation. It started out well -- we spent a few months hacking with Terraform, Docker, Vagrant, Kubernetes, and related technologies to implement an in
14.
by jammycakes 5y ago
The big problem that I have with Clean Code -- and with its sequel, Clean Architecture -- is that for its most zealous proponents, it has ceased to be a means to an end and has instead become an end in itself. So they'll justify their
15.
by jammycakes 7y ago
The problem with explicit error handling is that it's all too easy to get it wrong (by forgetting to check the return value) and when it does go wrong, it goes wrong silently, introducing a risk of leaving you with corrupt data. In pro
16.
by jammycakes 8y ago
Hi, author here. As other commenters have noted, this post is seven years old. My position on feature branches has evolved (and softened somewhat as well) in the meantime. I posted an update about 18 months ago: https://jamesmcka
17.
by jammycakes 8y ago
My apologies :) Incidentally I wrote a whole series of blog posts a while ago where I cast a critical eye over the whole n-tier/3-layer architecture and explained why it isn't all that it's made out to be. https://
18.
by jammycakes 8y ago
Well in the example I've just given they reduced query times from six minutes to three seconds. If that isn't increased efficiency, then I don't know what is. The fact is that sometimes you have to ignore the "rules,&quo
19.
by jammycakes 8y ago
> TL:DR Successive, well intentioned, changes to architecture and technology throughout the lifetime of an application can lead to a fragmented and hard to maintain code base. Sometimes it is better to favour consistent legacy technolog
20.
by jammycakes 9y ago
Pet projects need not take up all of your time. All you need is a few hours every so often — an evening or so once every couple of months, or one weekend a year would set you head and shoulders above a lot of people. The whole thing of dark
21.
by jammycakes 9y ago
I started keeping a comprehensive developer diary (I actually refer to it as lab notes) back in December, and it's made a considerable difference to how I think about what I'm coding. The way I write it is similar to test-driven d
22.
by jammycakes 10y ago
This. Also, I'd have thought that with weekend projects you're more likely to find things out by experimentation and reading the documentation than by asking questions. With work or classroom projects, you have to work with a fixe
23.
by jammycakes 10y ago
While 80 characters may be a bit restrictive, there is a need for a hard limit of something . I've found that in the absence of a hard limit, you all too quickly end up with a codebase riddled with 250+ line monsters forcing you to sc
24.
Software Engineers should keep lab notebooks(blog.nelhage.com)
3 points by jammycakes 10y ago|0 comments
25.
by jammycakes 10y ago
The Python interpreter itself may not do anything with the annotations, but static type checkers and linters can, and they will give you the safety that you need. The annotations also allow the development of better IntelliSense-like tools.
26.
by jammycakes 10y ago
Yes it is. The recommended approach these days for password resets is to email you a single-use, time-limited link to a page where you can choose a new password.
27.
Things that Subversion can't do(thingsthatsvncantdo.wordpress.com)
1 points by jammycakes 10y ago|1 comments
28.
by jammycakes 10y ago
If you stick to the rules, and you have only one branches/tags/trunk structure in your repo, and you actually set up the branches/tags/trunk structure in the first place, yes. But my whole point is that there's
29.
by jammycakes 10y ago
Number 2 makes me laugh: "Branches are expensive in Subversion - False. A Myth." Totally misses the point that the expense of branching and merging in Subversion is all in the UI/UX. Not only is it horribly cumbersome, it&#x2
30.
by jammycakes 10y ago
No they don't. Shelving and checkpointing have been planned for Subversion for several years now and though they're currently slated for version 1.10, currently in development, work on those features hasn't started yet. Given

More ›