A couple of weeks back, I met some of the kids from my old school. They had joined together to form a small team and were designing and deploying websites for local businesses.

Turns out that they were mailing each other and using Dropbox to manage the source code. This had been going on nearly for an year.

I spent a couple of hours showing them how to use git and gitlab. Basics on committing, pushing, pulling, branching and merging.

I will never forget the look on their faces! They had seen God and its name is Git.

rant? rant!

I work for a company that develops a variety of software solutions for companies of varying sizes. The company has three people in charge, and small teams that each worked on a certain project. 9 months ago I joined the company as a junior developer, and coincidentally, we also started working on our biggest project so far - an online platform for buying groceries from a variety of vendors/merchants and having them be delivered to your doorstep on the same day (hadn't been done to this scale in Estonia yet). One of the people from management joined the team working on that. The company that ordered this is coincidentally being run by one of the richest men in Estonia. The platform included both the actual website for customers to use, a logistics system for routing between the merchants, the warehouse, and the customers, as well as a bunch of mobile apps for the couriers, warehouse personnel, etc. It was built on Node.js with Hapi (for the backend stuff), Angular 2 (for all the UIs, including the apps which are run through a WebView wrapper), and PostgreSQL (for the database). The deadline for the MVP we (read: the management) gave them, but we finished it in about 7 months in a team of five.

The hours were insane, from 10 AM to 10 PM if lucky. When we weren't lucky (which was half of the time, if not more), we had to work until anywhere from 12 PM to 3 AM, sometimes even the whole night. The weekends weren't any better, for the majority of the time we had to put in even more extra hours on the weekends. Luckily, we were paid extra for them, but the salary was no way near fair (the majority of the team earned about 1000€/mo after taxes in a country where junior developers usually earn 1500€/month). Also because of the short deadline given to us, we skipped all the important parts like writing tests, doing CI, code reviews, feature branching/PR's, etc. I tried pushing the team and the management to at least write tests and make feature branches/PRs, but the management always told me that there wasn't enough time to coordinate and work on all that, that we'll do that after launching the MVP, etc. We basically just wrote features, tested them by hand, and pushed into the "test" branch which would later get tested and merged into master.

During development, one of the other juniors managed to write the worst kind of Angular code you could imagine - enormous amounts of duplication, no reusable components (every view contained the everything used in the view, so popups and other parts that should logically be reusable were in every view separately), fuck - even the HTML was broken (the most memorable for me were the "table > tr > div > td" ones, but that's barely scratching the surface). He left a few months into the project, and we had to build upon his shit, ever so slightly trying to fix the shit he produced. This could have definitely been avoided if we did code reviews.

A month after launching the MVP for internal testing, the guy working on the logistics system had burned out and left the company (he's earning more than twice the salary he got here, happy for him, he is a great coder and an even better team player). This could have been avoided if this project had been planned better, but I can't really blame them, since it was the first project they had at this scale (even though they had given longer deadlines for projects way smaller than this).

After we finished and launched the MVP, the second guy from management joined, because he saw we needed extra help. Again I tried to push us into investing the time to write tests for the system (because at this point we had created an unstable cluster fuck of a codebase), but again to no avail. The same "no time, just test it manually for now, we'll do that later when we have time" bullshit from management.

Now, a few weeks ago, the third guy from management joined. He saw what a disaster our whole project was. Him joining was simply a blessing from the skies. He started off by writing migrations using sequelize. I talked to him about writing tests and everything, and he actually listened. He told me that I'm gonna be the one writing them, and also talked to the rest of management about it. I was overjoyed. I could actually hear the bitterness in the voices of the rest of management when they told me how to write the tests, what to test, etc. But I didn't give a flying rat's ass, I was hapi.

I was told to start off by writing a smoke test for the whole client flow using Puppeteer. I got even happier, since I was finally able to again learn new things (this stopped at about 4 or 5 months into the project).

I'm using jest as the framework and started writing the tests in TypeScript. Later I found a library called jest-extended, but it didn't have type defs, so I decided to write them and, for the first time in my life, contribute to the open source community.

Hesitated for a while before posting this, as I don't like to whine in public but this should be therapeutical

Beware, it's a #longread

Years ago, I thought about how cool it'd be to have conversation-based interactive fiction on my phone. I remember showing early prototypes to my ex in 2012. It took me over 2 years to build up the courage to make it my priority and to take time off. FictionBurgers.com was born.

A few weeks in, a friend of mine forwarded me a link to Lifeline. I was devastated. I literally spent 2 days cursing my past self for not making a move sooner.

I soldiered on, worked 7 months straight on it. Now the tech is 90-95% finished, content is maybe 60% finished and I just... gave up. Every other week now, similar projects are popping up. I'm under-staffed and under-financed compared to them. Beyond the entertainment space, "conversation-based" is hot stuff in 2016, and I still can't seem to know what to do with what I have.

I feel like I had this fantastic opportunity and squandered it, which makes me miserable.

Anyway, just so you get some cheese with my whine, here are a few lessons I learned the hard way:

Lesson #1 : Don't go it alone. I thought I could hack it, and for over 7 months, I did. But sooner or later, shit gets to you, it's just human. That's when you need someone; just so that their highs compensate your lows and vice versa. Most of the actual writing was done by a freelancer (and he did AMAZING WORK, especially considering that I couldn't pay him much) but it's not the same as a partner, who's invested same as you.

Lesson #1.5 : Complementary skills. Just like my fiction project failed because I was missing a writer partner, my fallback plan of getting into conversational tech hit the skids for lack of a bizdev partner. It's great to stick among devs when ranting, but you need to mingle with a variety of people. Some of them are actually ok, y'know :)

Lesson #2 : Lean Startup, MVP. Google those terms if you're not familiar with them. My mistake here (after MVPing the shit out of the tech) was to let my content goal run amok : what made my app superior to the competition (or so I reasoned) was that it would allow for conversations with multiple characters! So I started plotting a story... with 9 characters. Not 2 or 3. NINE FREAKING CHARACTERS! Branching conversations with 9 characters is the stuff of nightmare -- and is the main reason I gave up.

Lesson #3 : Know your reasons. I wasted some much time early on, zig-zaging between objectives:
"I'm just indulging myself"
"No, I really want it to be a project that pays off"
"Nah, it's just a learning opportunity"
"Damn, why is it bothering me so much that someone else is doing the same thing ?"
"Doesn't matter, I just mine finished"
"What a waste of time !!"
etc etc
And it's still a problem now that I'm trying to figure out what to do!

So anyway, that's my story, thanks for readin'
Check out chatty.im/player/sugar-wars if you want to test the most advance version.

Also, I've also tagged this #startupfail, if any of you fine people want to share the lessons you've dearly paid to learn!

*team convo*

Dev: We will create another branch for the changes and merge them when required.

Director: Can we not do the changes in the current branch and comment them out until required? I think that’s cleaner and not confusing in my opinion.

Beautiful mf!

Ticket: Allow merchants to customize how their Wallet Passes look! It’ll be super easy, just add these nine merchant-modifiable strings (they support vars) and use their contents for text instead of what we use now. Simple!

Reality: There need to be 24 strings, there are some rules I can’t convey to the merchant (because the system literally does not include instructions, only a name and a textbox), the code to generate the wallet pass is inefficient, uncommented, branching spaghetti that I’ll need to rewrite (it seriously generates every possible field, and then only uses the ones it needs), the specs are so much worse, and half the default values they want aren’t even possible. As in, I don’t know if it’s a car loan, let alone the exact make and model of the bloody thing.

And no, sorry, we have no way of knowing what their fucking “vertical” is, either, so we can’t display that. Fucking sales.

Asdhkjfsjfads

WHY MUST EVERYTHING SUCK

My coworker can't be bothered with learning git branching, so he comments out significant functionality during testing and then comments it back in before go-live. What could possibly go wrong?

So my department is "integrating CI/CD"

Right now, there's a very anti-automation culture in the deployment process, and out of our many applications, almost none have automated testing. And my groups is the only one that uses feature branching - one of the few groups that uses branching at all beyond "master, dev"

So yeah... You could see how this is already ENTIRELY fucked from the very beginning.

First thing they want to do is add better support for a process... Which goes directly against CI/CD.

The process is that to deploy to production (even after it is manually approved by manager), someone in another department needs to press a button to manually deploy. This, as far as I can tell, is for business rule reasons rather than technical ones.

They want us to improve that (the system will stay exactly the same with some streamlined options for said button pressers)

I'm absolutely astounded at the way our management wants to do something but goes in exactly the opposite direction. It's like the found an article of what CI/CD was and then took notes on exactly what not to do.

It horrifies me how many "senior developers" in our company do not understand branching in code repositories....

I'm planning on writing an open source (and much improved) version of my logger, but I'm stuck on picking a name :<

So, anyone have naming suggestions for a tagged and branching/nesting logging library? (ES6)

(I don't think "deforestation" is a good choice. sounds kinda bad.)

WOW!! What a fucking cop out. After what happened yesterday about branching. my senior and our boss had a meeting and I wasn’t included. My senior then message me to next time dont create another branch just use the existing branch even if it was merged. I said “ok but i thought thats the best practice, we we’re doing that since the beginning”. Senior then responded “Whats best practice for our boss, that will be our best practice” what a fucking cop out!!! Bitch!!

Today on "How the Fuck is Python a Real Language?": Lambda functions and other dumb Python syntax.

Lambda functions are generally passed as callbacks, e.g. "myFunc(a, b, lambda c, d: c + d)". Note that the comma between c and d is somehow on a completely different level than the comma between a and b, even though they're both within the same brackets, because instead of using something like, say, universally agreed-upon grouping symbols to visually group the lambda function arguments together, Python groups them using a reserved keyword on one end, and two little dots on the other end. Like yeah, that's easy to notice among 10 other variable and argument names. But Python couldn't really do any better, because "myFunc(a, b, (c, d): c + d)" would be even less readable and prone to typos given how fucked up Python's use of brackets already is.

And while I'm on the topic of dumb Python syntax, let's look at the switch, um, match statements. For a long time, people behind Python argued that a bunch of elif statements with the same fucking conditions (e.g. x == 1, x == 2, x == 3, ...) are more readable than a standard switch statement, but then in Python 3.10 (released only 1 year ago), they finally came to their senses and added match and case keywords to implement pattern matching. Except they managed to fuck up yet again; instead of a normal "default:" statement, the default statement is denoted by "case _:". Because somehow, everywhere else in the code _ behaves as a normal variable name, but in match statement it instead means "ignore the value in this place". For example, "match myVar:" and "case [first, *rest]:" will behave exactly like "[first, *rest] = myVar" as long as myVar is a list with one or more elements, but "case [_, *rest]:" won't assign the first element from the list to anything, even though "[_, *rest] = myVar" will assign it to _. Because fuck consistency, that's why.

And why the fuck is there no fallthrough? Wouldn't it make perfect sense to write

case ('rgb', r, g, b):
case ('argb', _, r, g, b):
case ('rgba', r, g, b, _):
case ('bgr', b, g, r):
case ('abgr', _, b, g, r):
case ('bgra', b, g, r, _):

and then, you know, handle r, g, and b values in the same fucking block of code? Pretty sure that would be more readable than having to write "handeRGB(r, g, b)" 6 fucking times depending on the input format. Oh, and never mind that Python already has a "break" keyword.

Speaking of the "break" keyword, if you try to use it outside of a loop, you get an error "'break' outside loop". However, there's also the "continue" keyword, and if you try to use it outside of a loop, you get an error "'continue' not properly in loop". Why the fuck are there two completely different error messages for that? Does it mean there exists some weird improper syntax to use "continue" inside of a loop? Or is it just another inconsistent Python bullshit where until Python 3.8 you couldn't use "continue" inside the "finally:" block (but you could always use "break", even though it does essentially the same thing, just branching to a different point).

Bro every time this guy wants to create a PR, rather than branching off another branch and raising a PR to get it merged back in, this dude creates a fork and then makes a PR to merge the fork back in.

Holy. Fuck. Please don’t do this. It makes checking out your “branch” a massive pain in the ass. Plus, it’s totally unnecessary, and I can’t even check it out to begin with because your forked repo is fucking private you stooge. If we were in completely different orgs or doing open source I’d understand a fork. Not if you’re sitting right fucking next to me!!!!!111

We hired a new senior dev. The lead architect is going over basic bit branching and commits with him. This new job already feels like a dumpster covered in petrol.

First rant here, and it's going to be a query to the more professional and experienced members of society (most of you).

I am currently a Sys Admin for a major company, and I develop at night. My primary employment at the moment is the sys admin job (and I code for extra money at nights).

I wanted to start a development department at the company that I am working at, but it was turned turned down. It was stated that we are not branching in development, and that we should stick to our server implementation and support. This was a prompt to me wanting to start studying officially (I wanted to get qualified in JAVA, so that I had some paper behind my name when I looked for another job). HR and my directors outright denied me the ability to study through them (they pay for studies for employees) and I was more than fine with this.

I took a loan and paid for the studies myself. Can't crush a dream, you know?

The director caught wind of me studying, and now has demanded that I develop him a mobile application for the company. I told him that I am not a mobile developer, and that it didn't fall into my key performance areas.

Note, I do my coding on own time, on my own device, and never at work. It's fully my intellectual property. It also in no way interferes with my work during the day, and has NO conflict with my contract this side.

He sent an email yesterday, this is after two months. He is now stating that I WILL do the application, and he has CCd HR and two directors.

I don't want to do the app for this company, I spoke to HR previously about this, and she said that I should try and quote it under my own company name (which I did, but it was denied as it was "too expensive").

Now I am being forced to do something that is COMPLETELY out of my roles and responsibilities, something that this company has ABSOLUTELY no desire to go into further on, and he is basically letting me know that if I don't do it, he is going to start messing with my pay.

I really don't want to do this, and I cannot afford to make my secondary job my primary at the moment. The problem is, too, that I don't have the time during the day to develop AND do my sys admin tasks (I manage more than 300 servers, and 5000 devices).

What can I do in this instance? Or what would you guys recommend, in your experience?

Sorry for the noob question, but I don't know what to do.

I started contributing to my first open-source project today by branching youtube-dl and writing an extractor.

i was hired to join a team of old devs (40+) in an unnamed European country "yay goodbye 3rd world it's time to enjoy the quality of life" assist with enhancing already existing software and creating new solutions.
prior to my arrival most things were slow and super buggy, looking at the code base it shouldn't be a surprise, amateur hour everyone, logic implemented that is not needed, comment driven development, last time code review was done back in 1996. lots of anti patterns.
i swear there is a for loop that does nothing but it loops through a 100+ elements list, trunk based development with tfs since git is "not really needed"
test projects are not there.
>enter me an educated fool, with genuine passion for the craft and somehow a decent amount of knowledge.
>spent the last year fixing stuff educating people on principles and qualities.
> countless hours of training and explaining. team is showing cooperation, a new requirement comes in to develop with react.
> tear my ass creating reusable shit and self explanatory code with proper naming etc using git with feature branching, monday is first deployment day.
> today a colleague was working on an item submit a pull request and self approve it
> look at the code..... WTF the dumb fuck copied and pasted the whole code from different kendo components but somehow managed to refractor the name to test component, commented out all the code that he didn't use did the api call directly from the component, has 2 useeffects that depends on the a fucking text box changes for no reason, no redux implementation, the acceptance criteria is not achieved, and it doesn't work it just look right.
> first world country shit cannot scold, cannot complain, lead by example.
>asked him why you did this, the response was yeah probably i shouldn't have done that, i really didn't understand anything in the training but didn't want to waste time!!!!
> rest of the team created a different styled disaster with different flavors they don't even name their shit the same way.

fellow developers I'm stuck in a spaceship with a bunch of imposters, seriously i never cried in my entire life now I'm teary and on the verge of a break down.
talk with management "improving needs time" and offers me to join a yoga session to release the stress as if reaching nirvana would deliver shit on monday.
i really don't know what do is this a rant, is this a cry for help, I'm not sure, any advice is welcomed.

I no longer work for a startup company. On Monday I’ll start work for a real company, one that values project managers and their infrastructure. As a DevOps engineer, I value the IT resources that power my old companies SaaS platform. My old position is not being back filled and they’re hiring a full time dev instead of and Ops engineer. They have chosen to proceed with zero employees who know Azure or the platform their own software runs on.

Word to the wise when choosing to work for a startup. Ask these questions:

- Do they have a dedicated product manager/owner , who isn’t also the CFO?

- Do they value infrastructure and their IT resources ?

- Do they have decent powered laptops to work with?

- Do they have too much technical debt because they’re always building new features ?

- Do they work 18 hour days because they set poor work/life boundaries ?

- Who handles Support tickets , and what’s a typical support issue like?

- Do they have a branching and merging strategy? Don’t accept “we’re too small” as an answer! It’s a trap that they don’t want one.

I'm trying really hard not to be sensitive, but my manager is making it difficult with their "constructive criticisms" ...

Just finished up a call with them. And I'm so tired. I'm not even angry or upset, I just feel so tired of their bullshit.

I set up a meeting as a courtesy to get them up to date on all the code changes I made. Last night I stayed up late to try and get things in before the deadline and this morning just killed me when they say.

"I don't think I should have given you this."

"I was right, you weren't ready to start doing this."
(Then don't even bother giving me anymore tasks then, I don't fucking care.)

"you clearly don't understand how branches work"
(Absolutely fucking false, I fixed that shit and am very familiar with how to understand the structure of the fucking repo)

"you are rushing and I don't need you messing up the website"
(I'm being proactive you twat, not rushing, making it very difficult for me to do the work and being productive)

Like seriously bro! Don't fucking patronize me for the work I was trying to get out. And trust me this fucking meeting is done in order to get ahead of potential issues, not a time to be condescending of my skills or lack there-of as you seem to so keenly think.

If you had this much doubt about my abilities then why give me the fucking Sr. title? Fucking trust that I'm being honest, and I'm trying to get us to a good spot, not fucking sabotage the company. God fucking damn.

So now you want the old version? Now you want GIT? Now you want a branching model with CI? 1 year into the project?
FML

We're all on gradle and we had a new guy who started a project with Maven. He also used atom editor for Java/Scala code (even though we had a license for Intellij), and refused to use anything with code completion (or turned it off if there was an option). My boss had to explain basic git branching to him, his pull requests were missing build files, READMEs and he'd check in tons of scripts to run things instead of using maven/gradle.

I just thought he was weird, but I didn't look at his pull requests close enough to realize how bad his code was, until they fired him earlier this week.

So there is a 50/50 chance I am getting flamed af tomorrow during code review because of my branching/merging actions on thursday and friday... Merge conflicts... We all love them...

Randomly reviewing a coworker's c++ codebase revealed he was locking at the beginning of a critical section, but explicitly calling unlock for each and every error-handling branching within it. And yes, he forgot to unlock at several places.

That's just not RAIIght.

I'm trying to bring some structure to the IT department, but I need help with something. I'm on my feature branch for some front-end stuff. I realize that there is some back-end missing that my colleague must do. How should we go about tackling this? Should he create another feature branch, fix the things, merge to master, and then i can merge from master?

A newly joined developer (who was supposed to be very senior) comes and asks me how to write a test cos for some reason the person didn't know how to mock.

In Java,
(same for any other implementation which has an interface)
Writes Arraylist list =.....
Instead of List list = Arraylist...

Deployed code (another engineer from another country helped to deploy since this new senior dev didn't have access yet.

But the new senior dev didn't update relevant files in production code which brought down the site for nearly an hour. Mistake aside, the first reaction from this new senior dev is 'WHY DIDN'T THE DEV THAT WAS HELPING DIDN'T DO THE FILE UPDATE?'

This was followed by some other complaints such as our branching stragies are wrong. When in fact the new senior dev made a mistake by just making assumptions on our git branching strategies and we already advised on correct process.

Out of all these, guess this is the best part. The senior dev never tested code locally! Just wrote code, unit test and send to QA and somehow the test passed through. I learnt this when I realised this dev... has not even set up the local environment yet.

I keep saying new but this Senior dev been around like 3 months! This person is in another team within our larger team but shares same code base. I am puzzled how do you not set up your environment for 3 months. Don't you ask for help if you are stuck? I am pretty sure the env is still not setup.

Am I over reacting or is this one disgusting developer who doesn't even qualify for an intern let alone a senior dev? It's so revolting I can't even bring myself to offer help.

I have been working with git for years now, and I could never work on a project (regardless if big or small) without it. Its great.
However, just a couple of days ago I learned about the git flow branching model.
Even tho I also worked with branching on a daily basis for years, I did not know about this model. And I have to admit: Its awesome.
If you don't know it, I highly recommend you to look it up. It really improves the already organized workflow with git even more. :)

When you come up with a perfect working model for branching and merging, and everyone agrees apart from the one guy who insists you use gitflow because he likes shiny new things

(Warning: This rant includes nonsense, nightposting, unstructured thoughts, a dissenting opinion, and a purposeless, stupid joke in the beginning. Reader discretion is advised.)

honestly the whole "ARM solves every x86 problem!" thing doesn't seem to work out in my head:

- Not all ARM chips are the same, nor are they perfectly compatible with each other. This could lead to issues for consumers, for developers or both. There are toolchains that work with almost all of them... though endianness is still an issue, and you KNOW there's not gonna be an enforced standard. (These toolchains also don't do the best job on optimization.)

- ARM has a lot of interesting features. Not a lot of them have been rigorously checked for security, as they aren't as common as x86 CPUs. That's a nightmare on its own.

- ARM or Thumb? I can already see some large company is going to INSIST AND ENFORCE everything used internally to 100% be a specific mode for some bullshit reason. That's already not fun on a higher level, i.e. what software can be used for dev work, etc.

- Backwards compatibility. Most companies either over-embrace change and nothing is guaranteed to work at any given time, or become so set in their ways they're still pulling Amigas and 386 machines out of their teeth to this day. The latter seems to be a larger portion of companies from what I see when people have issues working with said company, so x86 carryover is going to be required that is both relatively flawless AND fairly fast, which isn't really doable.

- The awkward adjustment period. Dear fuck, if you thought early UEFI and GPT implementations were rough, how do you think changing the hardware model will go? We don't even have a standard for the new model yet! What will we keep? What will we replace? What ARM version will we use? All the hardware we use is so dependent on knowing exactly what other hardware will do that changing out the processor has a high likelihood of not being enough.

I'm just waiting for another clusterfuck of multiple non-standard branching sets of PCs to happen over this. I know it has a decent chance of happening, we can't follow standards very well even now, and it's been 30+ years since they were widely accepted.

When your process (branching and environment configuration etc) takes longer than the actual dev task 🙄 #onelinechange

Our Other it team asked me to create a new repository instead of a new branch in my project just cuz they thought branching would be more time consuming than maintaining a separate repo for emergency bug fixes.

Time spend with coding: 2 hours
Time spend with branching, merging, fixing merge mistakes and check if systemnis building again: 4 hours

What a miserable day...

Want to weed out bad Devop potential hires? Ask them how their ideal branching strategy is designed. Such a simple question will tell you a lot!

Can anyone of you help me.
I couldnt find anything on the internet, on how to remove that one branching commit, or how it got there in the first place.
(that commit and the one above it, introduce exactly the same changes)

... worst drunk coding experience?
none. or to be more precise, all of the three of them I had. I can't code drunk, i hate doing it, i hatw even thinking about doing it when drunk.

so after those initial three attempts i don't try to do it again, ever.

BUT, best coding experience while high?
ALL OF THEM.
some of the best pieces of code I wrote i did when I was high. my mind goes into overdrive at those times, and my thinking is not lines/threads of thought, but TREES of thought, branching and branching, all nodes of each layer of the tree coming to me AT ONCE, one packet == whole layer across all of the branches.

and the best was when one day, in about 14 hour marathon of coding while high, i wrote from scratch a whole vertical slice of my AI system that i've been toying around in my head for several years prior, and I had all of the high-level concepts ALMOST down, but could never specify them into concrete implementations.

and I do mean MY ai system, my own design, from the ground up, mixing principles of neural networks and neuropsychology/human brain that I still haven't seen even mentioned anywhere.

autonomous game ai which percieves and explores its environment and tools within it via code reflection, remembers and learns, uses tools, makes decisions for itself for its own well-being.

in the end, i had a testbed with person, zombie and shotgun.
all they had pre-defined in their brains were concepts of hunger and health. nothing more.

upon launching it, zombie realized it wants to feed, approached oblivious person, and started eating it.

at which point, purely out of how the system worked, person realized: "this hurts, the hurt is caused by zombie, therefore i hate zombie, therefore i want to hurt it", then looked around, saw the shotgun, inspected its class by reflection, realized "this can hurt stuff", picked the shotgun up, and shot the zombie.

remembered all of that, and upon seeing another zombie, shot it immediately.

it was a complete system, all it needed to become full-fledged thing was adding more concepts and usable objects, and it would automatically be able to create complex multi-stage, multi-element plans to achieve its goals/needs/wants and execute them. and the system was designed in such a way that by just adding a dictionary of natural language words for the concept objects on top of it, it should have been able to generate (crude but functional) english sentences to "talk" about its memories, explain what happened when, how it reacted, what it did and why, just by exploring the memory graph the same way as when it was doing its decision process... and by reversing the function, it should have been able to recieve (crude) english sentences that would make it learn what happened somewhere else in the gameworld to someone else, how to use stuff and tell it what to do, as in, actually transfer actual actionable usable knowledge to it...

it felt amazing to code for 14 hours straight, with no testruns during that, run it for the first time after those 14 hours, and see that happen.

and it did, i swear! while i was coding, i was routinely just realizing typos and mistakes i did 5-20 minutes ago, 4 files/classes ago! the kind you (and i) usually notice only when you try to run the thing and it bugs out.

it was a transcendental experience.

and then, two days later, i don't remember anymore what happened, but i lost all of that code.

and since then, i never mustered enough strength and resolve to try and write the whole thing again.

... that was like 4 years ago.
i hope that miracle will happen again one day...

I use version control as a glorified backup. Only recently did we start branching at work.

This is why I need to be part of a proper team where I can learn instead of being a team of 2 juniors and no one else 😂

Google's first result for "a-successful-git-branching-model" should be a mandatory read before you can get your git credentials established.

Once I really messed up with git. Lots of conflicts, strange branching, HEAD in detached state etc. Just cloned an earlier version of the repo into a separate folder, hand transferred all the changes I needed to keep and force merged into master as if nothing ever happened.

for my job I need to know,

Programming, C#, Optimization, Multithreading and Async code, Working certain tools, Reading difficult written code, Understanding, Physics, Networking, Rendering, Codeloops, Memory management, Profiling tools, Being able to make Jira tickets and read Jira tickets. Understanding source control branching, merging, push and pull. bug fixing.

And I write almost 1 line of code a week on average..

I'm a programmer.

I'm writing all the dev things I know in a docs site as a means to be hireable should I need to switch jobs.

I'm not gonna go too deep on how I'm doing it. One style I'm enjoying is making every article take only one page long, and if they take longer, maybe consider breaking it into another article.
Fuck long articles. Yes, that's a bit autistic.

But I will describe the challenges I'm finding (which are quite many) in further detail.

One of them is that words can be ambiguous. Production can mean the production environment but it can also mean production in plain english.
And there are tons of cases like this.

Because of this, I felt a lot of confusion in my beginner days. So it my objective to write this as to prevent as much confusion as possible.

Granted, I don't want to write "development for dummies". Software is complex. But because it's complex on its own, I don't want to add complexity to the learning process through obscure language usage.

"Fine", I say, "I'll disambiguate". But this means I find myself branching out very often into fundamental or commonly used software terms like "framework", "model", "scaffold", "algorithm", "viewport", "breakpoint", etc.

Another challenge is reaching good levels of completitude.
This means I have to explain that obscure CLI flag I never used in my life.

If I don't do this, then what makes my docs different than these superficial dev.to or medium posts? Nothing.
But trying to explain EVERYTHING about a software can generate a lot of frustration: I never finish.

It also makes me wonder "do I even know shit?". I think some amount of insecurity is healthy and pushes myself forward.
But at some point it's kind of making me feel like shit. Maybe I just need to keep learning.

emacs, git and a decent shell like bash with at least gnutools

emacs, because I was searching for the right editor for years
- multi-platform
- extensible
- ready to type (no fucking mode change for typing like vim)
- programming functions like auto indenting, syntax highlight, auto complete, etc.)
- multiple windows in any arrangement
Additionally
- it is completely programmable to do anything you want
- you can find a solution to most common development needs on the web

git, because
- it is usable from small personal projects to heavy duty development
- fast branching and checking out, switching between different workpaths within seconds
- basic version control offline, you only need to be online for remote consolidation
- you don't have to think much about structure from the beginning, if in doubt just commit and your work is saved, then arrange the result when you're ready

sh/bash-like shell with gnutools, because
- simple tools do their job and try not to be smarter than the user
- tools can be combined in any possible and impossible variants
- powerfull scripting (although sh-syntax is often annyoing)
- open as many shells as needed, no single-instance problem as with some GUI-tools
- extensible with gazillions of other tools

And best of all, all these tools are available on all widely used desktop OS.

Working with a data scientist on an update to a machine learning api that has dinner logic change with a new model.

He's wondering why his PRs are falling.

He's trying to merge into development from a branch created off of main.

He's renamed all the functions and classes and never updated the call points.

He's using new packages but never includes them in the requirements file, so the docket builds are failing.

His class method definitions don't contain self and are throwing syntax errors.

I've been working with him for 4 days to get him to understand branching, linting, unit testing, and not blindly copy and pasting snippets from jupyter notebook into production api code!

Alright, my very first post here was about this project and I am thinking it out loud again.

I see a problem and I am struggling to find a solution.

Now what I am thinking of is to articulate the problem well and state WHY I believe it needs to be solved. There are some reasons which must be presented in a capitalist way.

Furthermore, I am thinking of doing a market research to understand various demographics, validate the idea, and figure out the product-market fit.

Now, this qualitative research and quantitative data will help me decide whether it is worth putting in the efforts to solve the problem or not.

And since, we have an MVP already (funnily yes, we built it before all of the above), that will help me validate the tangible solution.

Once we get a confidence boost, then it will be time to get that single transaction which has net positive cash flow.

Start scaling to 'next billion users', so a billion transaction with net positive cash flow.

I won't be branching out into multiple verticals before be able to sustainably scale the core USP.

And while the second half sounds like, 'I have a million dollar idea', I am trying to be more and more realistic and rationale instead of falling in love with my idea.

I don't even have an idea (read solution) to fall in love with. Rather I have a problem that is bothering me.

So, yes, I am continuing this journey to solve the problem which started in second year of my hostel room and has evolved over 10 years.

is it necessary to have cherry picking a part of git branching/release process?

we have 3 branches : develop, release and master.

currently every dev works on feature as follows : they make a branch out of develop, write code, raise pr against develop, get it reviewed and merge back to develop. later the release feature list is generated, and we cherry pick all the release related commits to release branch, and make a prod build out of release branch. finally, the code is moved to master and rags are generated accordingly.

so the major issue with this process is feature blocking. as of now, i have identified 4 scenarios where a feature should not be released :

1. parallel team blocker : say i created a feature x for android that is supposed to go in release 1.2.1 . i got it merged to develop and it will be cherry picked to release on relase day. but on release day it is observed that feature x was not completed by the ios dev and therefore we cannot ship it for android alone.

2. backend blocker : same as above scenario, but instead of ios, this time its the backend which hasn't beem created for the feature x

3. qa blocker : when we create a feature and merge it to develop, we keep on giving builds from develop branch adter every few days. however it could be possible that qa are not able to test it all and on release day, will declare thaf these features cannot be tested and should not be moved to release

4. pm blocker: basically a pm will add all the tickets for sprint in the jira board. but which tickets should be released are decided at the very late days of sprint. so a lot of tasks get merged to develop which are not supposed to go.

so there's the problem. cherry picking is being a major part of release process and i am not liking it. we do squash and merges, so cherry picking is relatively easy, but it still feels a lot riskier.

for 1 and 2 , we sometimes do mute releases : put code in release but comment out all the activation code blocks . but if something is not qa tested or rejected by pm, we can't do a mute release.

what do you folks suggest?

My work product: Or why I learned to get twitchy around Java...

I maintain a Java based test system, that tests a raster image processor. The client is a Java swing project that contains CORBA bindings to the internal API of the raster image processor. It also has custom written UI elements and duplicated functionality that became available in later versions of Java, but because some of the third party tools we use don't work with later versions of Java for some reason, it's not possible to upgrade Java to gain things as simple as recursive directory deletion, yes the version of Java we have to use does not support something as simple as that and custom code had to be written to support it.

Because of the requirement to build the API bindings along with the client the whole application must be built with the raster image processor build chain, which is a heavily customised jam build system. So an ant task calls out to execute a jam task and jam does about 90% of the heavy lifting.

In addition to the Java code there's code for interpreting PostScript files, as these can be used to alter the behaviour of the raster image processor during testing.

As if that weren't enough, there's a beanshell interface to allow users to script the test system, but none of the users know Java well enough to feel confident writing interpreted Java scripts (and that's too close to JavaScript for my comfort). I once tried swapping this out for the Rhino JavaScript interpreter and got all the verbal support in the world but no developer time to design an API that'd work for all the departments.

The server isn't much better though. It's a tomcat based application that was written by someone who had never built a tomcat application before, or any web application for that matter and uses raw SQL strings instead of an orm, it doesn't use MVC in any way, and insane amount of functionality is dumped into the jsp files.

It too interacts with a raster image processor to create difference masks of the output, running PostScript as needed. It spawns off multiple threads and can spend days processing hundreds of gigabytes of image output (depending on the size of the tests).

We're stuck on Tomcat seven because we can't upgrade beyond Java 6, which brings a whole manner of security issues, but that eager little Java updated will break the tool chain if it gets its way.

Between these two components we have the Java RMI server (sometimes) working to help generate image data on the client side before all images are pulled across a UNC network path onto the server that processes test jobs (in PDF format), by reading into the xref table of said PDF, finding the embedded image data (for our server consumed test files are just flate encoded TIFF files wrapped around just enough PDF to make them valid) and uses a tool to create a difference mask of two images.

This tool is very error prone, it can't difference images of different sizes, colour spaces, orientations or pixel depths, but it's the best we have.

The tool is installed in both the client and server if the client can generate images it'll query from the server which ones it needs to and if it can't the server will use the tool itself.

Our shells have custom profiles for linking to a whole manner of third party tools and libraries, including a link to visual studio 2005 (more indirectly related build dependencies), the whole profile has to ensure that absolutely no operating system pollution gets into the shell, most of our apps are installed in our home directories and we have to ensure our paths are correct for every single application we add.

And... Fucking and!

Most of the tools are stored as source bundles in a version control system... Not got or mercurial, not perforce or svn, not even CVS... They use a custom built version control system that is built on top of RCS, it keeps a central database of locked files (using soft and hard locks along with write protecting the files in the file system) to ensure users can't get merge conflicts by preventing other users from writing to the files at all.

Branching is heavy weight and can take the best part of a day to create a new branch and populate the history.

Gathering the tools alone to build the Dev environment to build my project takes the best part of a week.

What should be a joy come hardware refresh year becomes a curse ("Well fuck, now I loose a week spending it setting up the Dev environment on ANOTHER machine").

Needless to say, I enjoy NOT working with Java. A lot of this isn't Javas fault, but there's a lot of things that Java (specifically the Java 6 version we're stuck on) does not make easy.

This is why I prefer to build my web apps in python or node, hell, I'd even take Lua... Just... Compiling web pages into executable Java classes, why? I mean I understand the implementation of how this happens, but why did my predecessor have to choose this? Why?

I went back and looked at some code I wrote a couple years ago. It made me so sad... I well and truely did not understand a lot of core concept yet at the time, and I was stubborn and thought what I was writing was good and refused to start over or delete code.

This try block had 4 FileInputStream objects and I even have a defined branching statement which I never use.

Whoever marked this assignment probably needed a lot of alcohol.

What is your preffered way of branching and potential integration of issue tracking?
Just curious to see as this topic causes a lot of discussions in office the last days.

!rant

Serious question: should I learn PHP?

I use the Microsoft stack at work, but I'm thinking about branching out a little. What do y'all think?

When I started branching out from frontend development and took an Intro to OOP course. I still do web, but getting more into the giant world of programming was really inspiring!

Just joined a new company and can only describe the merge process as madness.....is it or am I the one that is mad?!

They have the following branches:

UAT#_Development branch
UAT#_Branch (this kicks of a build to a machine named UAT#)

Each developer has a branch with the # being a number 1 to 6 except 5 which has been reserved for UAT_Testing branch.

They are working on a massive monolith (73 projects), it has direct references to projects with no nuget packages. To build the solution requires building other solutions in a particular order, in short a total fucking mess.

Developer workflow:

Branch from master with a feature or hotfix branch

Make commits to said branch and test manually as there are no automated tests

Push the commits to their UAT#_Development branch, this branch isn't recreated each time and may have differences to all the other UAT#_Development branches.

Once happy create a pull request to merge from UAT#_Development to UAT#_Branch you can approve your own pull request, this kicks off a build and pushes it to a server that is named UAT#.

Developer reviews changes on the UAT# server.

QA team create a UAT/year/month/day branch. Then tell developers to merge their UAT#_branch branches in to the previously created branch, this has to be done in order and that is done through a flurry of emails.

Once all merges are in it then gets pushed to a UAT_Testing branch which kicks off a build, again not a single automated test, and is manually tested by the QA team. If happy they create a release branch named Release/year/month/day and push the changes into it.

A pull request from the release branch is then made to pre-live environment where upon merge a build is kicked off. If that passes testing then a pull request to live is created and the code goes out into production.

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh it's a total mess. I knew when I took on this job it would be a challenge but nothing has prepped me for the scale of the challenge!! My last place it was trunk based development, commit straight to master, build kicks off with automated testing and that just gets pushed through each of the environments, so easy, so simple!

They tell me this all came about because they previously used EntityFramework EDMX models for the database and it caused merge hell.

I hate when a developer doesn't know how to use git. He never asks for advice or help until has pushes his changes up and creates a mess out of the main branch instead of creating his own feature branch. I mean there is no problem if you don't know how to use git, but you have a real problem if you say you know how to use it just to "look normal and experienced" and in reality you just don't know how to do stuff there. Just ask for help... and then if you create a mess out of git... Well, solve it and learn.

What branching methodology do you use and why? We've been using a trunk based development model, but I'm reviewing others.

When elements of an union are distinguished by a boolean, VSCode's Typescript plugin can only do type elimination if I branch by "== true" and not if I just branch by the boolean.
This is because Typescript treats booleans as an union of the constants "true" and "false", and compile-time elimination can only be done if I use syntax that makes sense with unions. Logical evaluation, for some reason, doesn't.
The fact that this issue can even appear is deeply concerning.

Questions more then a rant...

I've moved from being a lead on imploring DevOps and Agile practices in a large Telco to now working for a security consultancy... The team I'm with are s*** hot when it comes to SecOps (which is why I changed jobs) and I've been hired to he the automation and working practice expert on the team. Already got some of them learning Ansible which is a great start!

I've got delivery now being pushed to Git and all client work being tracked in Jira and properly documented and collaborated through HipChat and other CI tools on the way....

My question is this... Does anyone have some awesome resources to teach people Git, Jira, Jenkins, etc. quickly without forking or branching out on expensive training? Focus on being a technical but consultative team. Ideally just wanna pull some awesome guides and make. My own commits on them for the team... Please fire a story or epic away!

currently setting up a repo for a git release branching demo because despite the fact we have a model in place, it was completely ignored when it came to release time with changes being pushed straight to the main develop branch *sighs*

I've having issues trying to form a proper branching strategy for my mean stack app deployment.

Heroku creates staging and prod branches for my web app so I'm a bit confused if I need my own staging branch?

Currently I have this: feature -> dev -> staging -> heroku staging (the staging branch seems useless)

Also, Heroku allows you to promote heroku staging to heroku prod, so there's no point in making master push to heroku prod.

I'm thinking of making my strategy to the following, but wasn't sure of any pitfalls or anything I'm overlooking long term.

feature -> dev -> master -> heroku staging -> manual promote to heroku prod.

Any suggestions?

"Nah, branching is too complicated, I'll just create an entire new git. It's faster."

!rant
had to give a short presentation on the origin of OOP at work. It turned into a neat little discussion on what OOP means to you based on your experience and what you've been taught. I had always thought it just meant working in terms of objects and polymorphism, inheritance, etc. were good practices.

Found it interesting that when I started reading into Simula, Smalltalk and Alan Kay's work, early 'uses' of OOP were different from each other and today. To me it seems it have originated obviously, from the desire to work with real world objects but branching off to being more closely related to the actor model and the idea of message passing.

Was wondering if anyone else has looked into this topic or has their own opinions based on experience.

Guys, how do you structure branching in an enterprise project?

We're using git, managers are MIA, I'm basically helping another new guy kick off and maintain the projects that we have.

What would be a good branching strategy? Front end and backend in the same project, 5 man team in the future.

When you discover the "branching strategy" is not far off copying the working directory as a backup -_-

Is git a history of what happend or a list intentional changes?

Had this discussion with my boss. He said i shouldn't rebase my feature branch because it is too much hassle (I did some squashing and fixups). I should just commit on top and merge master into my branch.

What is your git philosophy?
Do you "own" a feature branch until you create the PR?

How does Git collaboration on a web text editor/web IDE works behind the scenes (like that of GitLab)? Do they shallow copy the git repo per user working on it and apply any operation (like branching, merging, rebasing) over that or how does that works?

Feature Toggles should not be used instead of a proper branching strategy.

Branching. Am I right?