Programming as a career

a standard regex query in sql sounds neat

the problem is probably related to a bunch of vendors coming up with extra shitty versions of useful features, fighting over what should be standard

a coworker did a presentation explaining how oracle’s xml querying (which was probably an insanely bad idea anyway) was so fucked they actually tore it out of a newer version and retooled it

generally if you want to do document storage or mongo stuff, just... use a document storage db. relational databases don’t need to include every damn thing and doing so just encourages people to do very bad things

I can see not wanting to include regexes out of the box, since it's possible for an unlucky combo of regex and input string to max out CPU and bring the server to its knees. I think it was a bad regex that brought Cloudflare offline a few weeks ago.

yep that was a great postmortem.

who decided that percentages in en-US should have a space between the number and the percentage sign and can I shake them until their teeth rattle?

that thing where it's easier to rewrite the code than it is to debug it.

(somewhere in ~3000 packets the data is getting out of sync but this only manifests as an error in the last packet. just can't nail it down)

((there's a peculiar case where you've got just enough data to go into a fixed-length packet but when you've added the extra 2 bytes to say that this is the last packet you no longer have the space for the all data, so this ends up being the last-but-one packet and you have to add another packet containing a single byte))

fwiw, the second attempt at the code is much neater.

as long as you're sure the original code didn't have obscure and undocumented but vital side effects...

it's ALL obscure and undocumented side effects.

(it's not, it's new, non-production code, something i wrote 3 weeks ago and have spent the last two debugging. file in, slightly modified file out. unfortunately the output is fixed-length packets and some of the modifications add / remove one or two bytes from some of the packets, meaning all the rest of the data has to shuffle down and new packets may be created)

code review. github tells me 84 files have changed. +769 -451 lines

in those files there are *4* comments, all similar to this (but with different numbers, 1-4)

    generateNoof(malUnits),  // #1

the "84 files changed" aspect of that is really what scares me the most

we recently went on a big code formatting kick and committed basically our entire codebase which sucks because now the 'show annotations/history' feature in RAD points every line to that one revision cuz it replaced all the tabs with spaces

my last job the codebase had a "tabs-to-spaces" commit that messed up git blames but it's possible to skip over it/reblame starting before that commit in various ways

cf git blame --ignore-rev

it's a refactor of some classes into smaller classes. so all the test classes need refactoring too. and then some test utility things have been changed to static methods so everything that used them have also changed.

(it might also be that the 84 is for the entire pull request whereas i've only looked at the first commit so far)

and some default formatter keeps dicking wih comments so you end up with stuff like

// very long comment that would be fine all on one line but the formatter
// disagrees

wait, is RAD whatI think it is? If so, condolences

I finish bootcamp in two weeks, gang! :D

Congrats...was this an online bootcamp? How was it affected by covid?

Which one did you do? Was it a Rails one, or JS, or something else?

I did ReactJS!

I went to an actual campus six days a week until the COVID lockdown

my last job the codebase had a "tabs-to-spaces" commit that messed up git blames but it's possible to skip over it/reblame starting before that commit in various ways

― silby, Tuesday, April 28, 2020 12:17 PM (four days ago) bookmarkflaglink

cf git blame --ignore-rev

― silby, Tuesday, April 28, 2020 12:17 PM (four days ago)

Oh nice! https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

Cool

lmao I didn't even realize that was a new feature, I perhaps haven't actually used that yet. idk whatever.

anyway, condolulations Whiney

Thanks!

definitely going to make use of --ignore-rev from now on but it'll be a pain to set that up for every giant squash merge.

squash mergers being fucking savages is the only programming hill i'm willing to die on

sorry whiney but you have to turn in your cool badge at the security desk now, prepare to be bullied, NERD

breh if i'm working on a giant project i'm definitely squash merging my fuckton of commits into 1 for the sake of keeping the master branch clean

smh if you aren’t interactively rebasing your feature branches into a glittering necklace of logical and well-described commits.

sorry whiney but you have to turn in your cool badge at the security desk now, prepare to be bullied, NERD

― j., Sunday, May 3, 2020 2:50 PM (two hours ago) bookmarkflaglink

going from "geek" to "nerd" will be a difficult transition but not an impossible one

It's been fun meeting people who have no idea what noise music is!

silby otm.

Just you wait, Whiney.

having a true commit history is infinitely more useful than having a clean master branch. also you should be doing what silby said

always said i'd leave ilx after stet adds inline manscaped adds

Congratulations whiney!

I did ReactJS!

Welcome fellow ReactJS dev!

"I did ReactJS!"

How is the 40 hour course on Udemy, anyone know?

Which one is it? Don't pay full price, the courses are often 90% off!

https://wesbos.com/courses is definitely worth a look

also worth noting is that react has some of the best documentation I've come across -- had to learn enough of it in about two-three weeks for a quick project, and that definitely helped

of course the downside to it is that I can't really say I know it, I just know enough of it to make stuff and google in the gaps

That describes nearly all software developers. The rest don’t know how to use google.

i was gonna say tbh

I guess my point was more, it's definitely possible to learn on your own, particularly if you have experience with coding/specifically javascript, but a course formalizes that, if that makes sense

My experience is that the formal stuff crops up more often in interviews, although at the same time there are some things that fall into that category but which I've internalized as Just Something You Should Know.

Which one is it? Don't pay full price, the courses are often 90% off!

https://wesbos.com/courses is definitely worth a look

― cherry blossom, Monday, 4 May 2020 bookmarkflaglink

It's this one:

[Removed Illegal Link]/

I have a free pass. My background is Data not web Development (SAS, SQL), know the project lifecycle etc.

I am currently picking up some Python and like R (doing a course of each for the next 1-2 weeks), but was wondering about a JS course.

Let me try that again:

https://www.udemy.com/course/modern-react-bootcamp/

(Only have it for free due to my company's account, not sure how long that will last)

I don't know that one but just the other day I was recommended 'The Advanced Web Developer Bootcamp' by the same author

My hot take is that by this point all courses are probably good. The only danger I think with courses is you follow along and build the app and maybe some of it is easy and some of it is hard, you follow along the path and get to the end, and think I kinda got this. Then any slight divergence doing your own thing and you're off the path and in the weeds drowning.

I think there's a lot to be said for the opposite approach, building things from the ground up and googling how to do each step. The reason primarily being each thing sticks a lot more, you don't lose what you've learned. There's definitely a danger with following courses/tutorials alone that it doesn't stick. A combination is best, smaller apps/projects for the second because its tougher than following a course

google in the gaps

This is the best skill to have, especially given the weird things that can come up you would never be able to prepare for!

Thats more of an all purpose answer, looks like differnt people have different needs/goals!

Lots of good courses to get a start on the basics but yes googling around the labyrinth of answers when something unexpected comes up and working through problems is almost like the key skill, whatever you code/script in.

I just want to say I was very anti-squash right up until the first time I had to rollback something out of the dev branch that hadn't been squashed; now I am all "if you do not squash that shit before merging, I will murder you"

smh

Right, BEFORE merging, not AT THE MOMENT OF merging.

If you're not committing to the trunk multiple times -- meaning that your changes are in an isolated feature branch that is eventually merged into trunk -- then you can revert all of that stuff by reverting the merge commit.

Squashing, being a manual process, always introduces the possibility of human error.