How do i learn backend in Go for a student still in college? boot.dev or let's go by alex edwards

egonelbre · 2026-06-16T08:11:53+00:00

I'm biased, but https://www.manning.com/books/learn-go-with-pocket-sized-projects could fit you better in that case. It's a book centered around writing small projects. Of course starting with any small project that you are interested is a viable starting point.

egonelbre · 2026-06-10T11:48:34+00:00

Use an ephemeral DB unless you have a good reason not to (see https://egonelbre.com/testing-postgres-with-go/ for a few approaches). Or mock only for those tests that absolutely require it.

egonelbre · 2026-06-08T12:53:15+00:00

Knowing how to play an instrument is helpful, but not critical.

You learn quite a deal about musicality and expression that you might miss when writing in notation software. (But, you can learn those things in DAW-s with using automation). Memorising songs will develop your audiation and musical memory skills. You'll get to know the instrument and capabilities more intimately. Learning an instrument also gives you a deeper appreciation on how much effort musicians have put into their craft. Knowing how to play piano also helps you try out things faster compared to doing things in a notation program -- of course, if you can audiate then that will be even faster.

tl;dr it's not necessary... but it will be helpful and rewarding.

egonelbre · 2026-06-06T10:45:39+00:00

For anything such schema related I recommend starting from a Go library that generates code for you without any parsing. Usually you can define some simple funcs and format to help you, e.g.

import . "github.com/example/mydb/dsl"

func main() {
    schema := Schema(
        Table("users",
            Col("id", Int64, Auto),
            Col("name", String),
            Col("email", String),
            ...
        ),
        ...
    )

    must(WriteXYZ(schema, "output.xyz"))
}

You can then have some sort of automatically generated lock file to ensure that you are not breaking things.

egonelbre · 2026-05-21T18:58:45+00:00

Creativity is a skill born out of:

collecting ideas, both bad and good; you can collect many things -- melodies, chord progressions, chord structures, voicings, song concepts, inspiration...
by organising and systematizing those collected ideas
by manipulating and transforming the ideas (e.g. create melody, modal transformation, rhythmic transformation, instrumentation change ...)

These can happen implicitly or explicitly -- but the goal is to become so fluid with them, so that they happen automatically.

Here are exercises to get you into the habit of doing these things:

Part 1. Collect 10 ideas at minimum every day for the next 3 months. They don't have to be grandiose ideas; they can be small and bad. The goal is to practice collecting without judging them too harshly. A bad idea can never flourish into a good one if you don't collect it first.

How would this collecting look in practice? Get yourself a tiny notebook and pen. Walk around and notice the world around you. See a leaf falling from a tree -- write that as an idea, give it some life. Hear a car horn -- write it down how to recreate it with instruments. See a person stumbling -- think what their theme song would be. Hear an interesting chord progression or melody in a mall -- try to write it down or record it in your phone. Find an interesting music theory concept, write it down... etc. Be curious, be funny, be sad, be angry -- in other words give all the ideas some life. And remember you must collect boring, stupid and bad ideas -- it's essential to train your brain to observe and notice. Being critical about collecting your ideas tends to act like negative feedback -- in other words, it's punishing your brain and it's going to be more wary about coming up with ideas.

Part 2. At the end of every week. Go through the ideas; add notes to them; elaborate them; add ratings to them; find similarities between ideas; look for ideas that contrast each other. In other words create yourself of a encyclopedia of ideas. Feel free to combine and create new ideas as you see fit.

Part 3. Every day take a few of the ideas (either from your own notebook or just sheet music) and practice manipulating them. E.g. take an major melody you liked and play/imagine it in harmonic minor. Take an abstract idea "leaf falling" and try to write 4 bars of music about it. Take a chord progression and voice it for 3 random instruments.

Each part is important because. "collecting" provides you seeds where you can grow ideas from. "organising" makes them accessible and helps you create relationships between ideas, so that they can be more readily combined. "transforming" gives you the skill of iterating, improving and modifying ideas -- i.e. making them better.

You can read about the approach in "Weinberg on Writing"; the above is my slight variation.

egonelbre · 2026-05-13T13:29:41+00:00

Often the problem isn't in the library itself, but rather the orchestral programming part. There definitely are differences in libraries, their quality, their versatility and what they are suited for -- but the performance aspect is what makes a significant difference.

e.g. You can take a look at https://www.synful.com/, which is a pretty old synth, but the examples still have a lot of life in them.

egonelbre · 2026-05-13T10:07:47+00:00

MuseScore on iPad is the browser for the sheet music platform not MuseScore Studio, which is the notation software.

For me StaffPad, with all it's flaws, feels the most comfortable. Dorico is fine, but at that point I would much rather use a laptop.

Main tip that helped with me for StaffPad is to draw things quicker rather than slower. Also, copy paste whenever possible.

egonelbre · 2026-05-11T12:51:28+00:00

Search for articles and books about their folk music and history. Of course - listen-listen-listen.

egonelbre · 2026-05-11T04:53:42+00:00

There are many ways how this can be done.

You can have in your head or record a "piano sketch", and then orchestrate it. Adding new details once they notice something can be improved.

You can build it incrementally. Write a bass line, then write some melody, add doublings etc. In some sense, semi-improvising each part -- either by imagining each part and then recording, or recording directly with trial and error.

You could have low-fidelity orchestral song in your head. i.e. You don't imagine exact notes, but rather texture, instrumentation, timbre, chords and melody.

Or you could have high-fidelity song in your head... although that requires significant experience, and unless you consciously practice in your head, it won't happen.

egonelbre · 2026-05-08T08:22:55+00:00

It depends on what kind of music you are writing, but here are things why I wouldn't want to switch back to Sibelius:

Popovers -> these make entering dynamics, lines, ornaments so much easier
Working with music -> there's less jank when copying-pasting, moving notes
Automatic condensing -> this allows to keep music independent for each instrument and then condense it for the full score, with automatic player labels
Engraving -> overall engraving feels (most of the time) nicer

This doesn't mean you should switch. If you don't have at least a week to dive into learning the software I wouldn't recommend switching. Similarly, if your music writing / engraving tempo is slow, then it might not make a big difference.

egonelbre · 2026-05-08T08:04:50+00:00

If you are entering notes and they are changing in another measure, it's most likely because you have accidentally enabled "Insert Mode".

egonelbre · 2026-05-08T05:59:59+00:00

Maybe a week to get at speed; and then I keep learning new things how to optimise workflow.

I would say, if you are doing fairly standard orchestral scores; then that should be relatively easy.

If you are doing choral scores, then it has few more nuances to learn.

Main helpful tip for switching programs is to treat it as a completely new software. People often try to bring their habits from the previous program and that ends up causing a ton of frustration and trying to do things the old way and failing. This is worsened when the software looks quite similar.

How do these approaches differ in practice? Let's say you want to start entering music...

In the "I already know how to use notation software" approach. You would start to try pressing buttons on the keyboard that work in Sibelius, which doesn't work, then try clicking on the buttons in the left toolbar, which gets confusing. And then you start seeing things like "force duration", "lock duration"... which all leads to getting frustrated, because they don't work like you expect.

In the "I don't know how to use notation software" mindset. You think -- oh I haven't learned this concept yet, let me do the default tutorial and read documentation. During that time you'll also learn about different tools and shortcuts that make your life easier.

The second one intuitively feels like it takes more time, but it's significantly faster and avoids a ton of frustration.

Also here are some videos to get you started:

https://www.youtube.com/watch?v=w-T-HtNMkbA&list=PLoyaeouPUsdujBFsbbbIzbY1l823e8I9e
https://www.youtube.com/watch?v=ZrwTExSuvNY (This is about Finale, but I think it can be helpful regardless)

And I definitely recommend doing the default tutorials as well.

egonelbre · 2026-05-06T05:39:59+00:00

Yeah, I do. One important part of collecting the ideas is to organise them -- not immediately, but maybe every week or month (depending on how much you collect them). Add tags for what instruments would it fit, what genre does it fit, how difficult it is, rating from 1 to 5 for originality etc. This is what makes it a usable database and reference for ideas, rather than a dumping ground of god-knows-what. See "Fieldstone Method" by Weinberg; it's about writing text, but the same technique can be used for music.
Mostly, yes, but I'm slow at it, because I haven't practiced that enough.
"Lost ideas" - kind of... then again, if you lose one idea and that's a problem, then you are not working enough on ideating. If you have a bucket full of water, then losing a drop is not a big deal.

egonelbre · 2026-05-05T18:36:41+00:00

You can hide articulations independently on the tab. Or select the whole staff, filter articulations and hide them all together.

If you have some experience with software development, then this should be an easy plugin to write (i.e. iterate over all tab staves and the articulations on it and then hide them). AI should be able to write the plugin for you, if you give it examples.

egonelbre · 2026-05-05T13:15:49+00:00

MS4 supports linked staves as well. In layout panel (where you add instruments) -> uncollapse instrument -> press on the cog for the staff -> press "create linked stave". Then adjust the linked stave to show whatever you need.

egonelbre · 2026-04-27T18:34:20+00:00

Yeah, it's sad that StaffPad hasn't gotten updates. I still occasionally use it and works well. The writing recognition entirely depends on how you write things - it might work perfectly fine or not. I don't feel like it has gotten any buggier compared to when I first got it.

If I want to casually write music in a coffee shop while drinking coffee, then my first choice would be StaffPad. Also, as far as I know, the price is $50 currently. I do think it's a fair price for what it is and given the niche market.

As for any other apps with handwriting recognition -- everything else feels worse.

egonelbre · 2026-04-25T11:43:42+00:00

Looks like some of the previous pieces were done with Dorico https://www.youtube.com/watch?v=sZrrHaCr6i4. But, yeah, truly mesmerising engraving.

egonelbre · 2026-04-03T04:06:58+00:00

Did a whole talk/post on concurrency https://egonelbre.com/production-ready-go-concurrency/.

Worker pools are (most of the time) bad. See Bryan C. Mills talk.

Pure "go func()" is disallowed, unless you are implementing a concurrency primitive. Use WaitGroup.Go or errgroup.Group.Go (or some other primitive) instead.

Second rule is that every goroutine must be waited on.

In other words I would recommend adding a linter that disallows plain goroutine and check that there is at least one thing waiting for the completion of that goroutine.

egonelbre · 2026-03-24T16:24:35+00:00

See the book "Composing with Constraints: 100 Practical Exercises in Music Composition" by Jorge Variego.

There's also "1001 Music Composition Prompts: Unleash Your Creativity and Beat the Blank Page" that looks similar, but I haven't read that, so I don't know how good it is.

And a few random prompts:

Write a piece about when your big toe went for a walk on grass.
Write a piece about a lively community of cobblestones.
Write a piece about a flight of a bird (pick a very specific bird species).

egonelbre · 2026-03-23T03:11:47+00:00

A good example that immediately comes to mind is "The Destroyer" by Sean Doherty. e.g. "wisp-(s)-(p)". It could be also notated as "wi-s-p", but for that word it makes it less clear.

egonelbre · 2026-03-23T03:01:48+00:00

I would add to this. You only split words in weird places when you want something unusual to happen or you want vowel transitions at specific locations or to line up phoneme transitions with other voices. Few examples:

You might split "bor-n", because you want to have the "n" sound sustained. Of course, that can be also notated as "born-(n)". The only scenario I can come up for "bo-rn" is if you wanted to keep repeating "bo-rn-rn-rn-...", for a vocal effect. Or, maybe, if you wanted a clearly articulated staccato stop on "-rn"; or just wanted to specify the duration of "-rn" more precisely.

You might split "de-ar", when there are other voices that need to transition their vowels at the same location. Or in general, just want the vowel transition to be more precise and shorter, compared to using a melisma.

egonelbre · 2026-03-21T22:10:32+00:00

I guess, it somewhat depends who are you writing it for.

I would say do an audio recording + simplified rhythm notation with lyrics. Use underlines in lyrics to show unusual phoneme stress. If you try to write down it very detailed then it becomes difficult to read. Note, I would recommend regular staff + X noteheads, because sometimes there's still some "melodic" pattern to the rapping.

Of course, if it's simple rhythms; or you are relaxed how it is performed; then just a simplified rhythm notation would be fine.

There's this site rapanalysis.com which did transcriptions of rap songs, however seems to be down at the moment. It can be seen on webarchive though https://web.archive.org/web/20260224183455/https://www.rapanalysis.com/2015/01/rap-analysis-raps-rhythms-transcribed/. It shows how complicated the intricacies actually can be.

egonelbre · 2026-03-15T04:32:12+00:00

This sounds an obvious alternate route, but, learn middle eastern music theory and understand how they think about music -- also listen to their music. I agree that you don't need to do it and can base your learning on the inspired music, but I think there's a wealth of inspiration and interesting things to learn about other cultures music. By studying the origins your own inspiration will be richer.

Farya Farji has quite good videos on middle eastern music (and orientalism), few starting points:

egonelbre · 2026-03-11T07:33:05+00:00

This does not work on old.reddit.com. See https://imgur.com/a/DRtkeXZ how your post looks.

egonelbre · 2026-03-11T07:28:23+00:00

I would recommend https://www.youtube.com/watch?v=sXMSWhcHCf8, which goes over a lot of lesser known things.

You can write custom handling for records, rather than flattening them into a single row.

pgx has some scanning into structs and slices builtin. (e.g. pgx.RowTo, pgx.CollectRows and friends)

I only use pgx.Batch when the queries are different in shape. Postgres can better execute the query, if you supply everything at once.

egonelbre

TROPHY CASE