n-1 🤣 -- Not all of them 😅
n-1 🤣 -- Not all of them 😅
The automatic migration at startup simply exist to make *my* life easier. I not only operate this thing locally when developing, but also on a test and production environment. It's very convenient if the existing prod and test data just keep working with a new software version and I don't have to manually migrate things by hand. Simply start the new software version and voilà. I really don't wanna miss that.
Since I don't enjoy doing admin stuff, there is one big thing to not worry about. Even though I messed up one migration step so far and had to fix the production database by hand (removing all existing sessions by hand, so that a new column without default value could be added). It worked flawlessly with the test and local databases before, though, no active sessions did exist anymore at the point of deployment). That raised my adrenaline level.
I reckon I keep the supported versions to a minimum from now on. At least as long as I am absolutely sure that I'm the only person operating that software.
All the black stuff on the shore of the pool are tad poles. Technically, there are hundreds of them on the flooded forest road. :-)
Tad poles on the flooded roadhttps://lyse.isobeef.org/waldspaziergang-2024-05-31/
yarnd instance and all that is handled transparently by the app anyway.
yarnd instance and all that is handled transparently by the app anyway.
User-Agent is reported incorrectly 😅
User-Agent is reported incorrectly 😅
> bmallred may not follow you
> bmallred may not follow you
blow off stress between meeting followed by an excuse to go outside with no comms.
#running
blow off stress between meeting followed by an excuse to go outside with no comms.
#running
blow off stress between meeting followed by an excuse to go outside with no comms.
#running
"GET /twtxt.txt HTTP/1.1" 200 27110 "-" "nahongvita/0.1.0 (+https://staystrong.run/bmallred/twtxt.txt; @bmallred)"
"GET /twtxt.txt HTTP/1.1" 200 27110 "-" "nahongvita/0.1.0 (+https://staystrong.run/bmallred/twtxt.txt; @bmallred)"
#running #treadmill
#running #treadmill
#running #treadmill
(What’s that black spot in the upper right corner?)
No photos to share at the moment. 🫤
(What’s that black spot in the upper right corner?)
No photos to share at the moment. 🫤
(What’s that black spot in the upper right corner?)
No photos to share at the moment. 🫤
(What’s that black spot in the upper right corner?)
No photos to share at the moment. 🫤
$ cp live.iso /dev/sda
$ sync
E tá feito
$ cp live.iso /dev/sda
$ sync
E tá feito
DROP and CREATE COLUMN of existing tables. Wow! Alrighty then, removing the migration, here we go.
# No Interface Is A Good Interface
First of all, don't start out with an
interface right at the very beginning. Only create one if you later on come to the conclusion that you really have to, because chances for truly needing one are actually slim.I experience that at my dayjob, too. There is a code base where I always wonder why certain interfaces exist in the first place. They're all implemented by exactly one type each, which is kind of useless. Just the type alone would totally suffice.
That train of thought to always also have an interface along with an implementing type might come from the Java enterprise world, at least that's where I encountered it really heavily. I never liked that. It just makes the code arbitrarily more complicated than it needs to be. The best code is the one that doesn't even exist. Simpler is better. Complexity is the root of all evil.
Advocates of the type with interface faction then like to argue: "But maybe sometime in the future we would like to create a second type that implements this interface, you will never know@11!! Or think of refactoring, we can also change the underlying implementation completely when we have an interface in front of it without people knowing!" But that basically never happens in reality. It reminds me a bit of premature optimization, preparing for the unknown future. Firstly, things turn out differently and secondly, other than one thinks. :-)
To be fair, thinking about what might happen or not is still a very valid thing. In my opinion it is even done not enough in this agile world. Implementation first, consideration second (if at all). But there are limits. So, start out simple. No interface for you at first.
That general rule goes at least for application development, it can be a little bit different when you write a library. More flexibility _might_ be actually helpful there.
# Interface Placement
When you define an actually beneficial
interface, then place it in the same package where it is actually used in. Or lexically close to where is is used for that matter. As oposed to in the package where the implementing type resides in. This recommendation is very logical to me. The interface describes the API, so it should also go along with the rest of our API.# Return Values
When you have a factory function to create a type that implements an interface, return that implementing type, not the interface. Using ugly suffixes in identifiers to help visualize the concept:
o
type FooInterface interface {
Foo()
}
type FooImplementation struct { }
func (f *FooImplementation) Foo() { }
func NewFoo() *FooImplementation /* as opposed to FooInterface */ {
return &FooImplementation{}
}
Most of the time I agree on that rule (it feels natural and correct), sometimes I don't. I reckon this depends on the exact use case at hand.
# Testing
When you have a type that you want to test, the recommendation is to not create dedicated interfaces for testing purposes only in order to mock something. If you do, this smells like a bad API design of the type in the first place. Instead, try to make its regular, productive API better, so it can be also used when testing the type.
Phew, this turned out to be a much longer post than I first anticipated. ;-) I hope this helps a bit.
Just haven't figured out where exactly the speedup comes from. I suspected that the column recreation is kind of expensive, but it doesn't really appear to that obvious. More testing is needed.
(Media od the day)An interesting fog formation early this afternoon in the park tha our house backs on to, in full daylight 😱
What about y'all? Anything interesting to share today? 🤔
(Media od the day)An interesting fog formation early this afternoon in the park tha our house backs on to, in full daylight 😱
What about y'all? Anything interesting to share today? 🤔
I don’t remember having seen bender’s key, though. Maybe that one works. I might give it a try some day, when my motivation is back up. 😂
I don’t remember having seen bender’s key, though. Maybe that one works. I might give it a try some day, when my motivation is back up. 😂
I don’t remember having seen bender’s key, though. Maybe that one works. I might give it a try some day, when my motivation is back up. 😂
I don’t remember having seen bender’s key, though. Maybe that one works. I might give it a try some day, when my motivation is back up. 😂
Blackbirdhttps://lyse.isobeef.org/amsel-2024-05-29/
I should have taken a video of that gorgeous bird.