Just reached 100+!!

Anyhow. I started coding prettymuch 365 days ago. My mate decided to launch his company and figured it was a good idea to start it with good friends who knew fuck all at coding.

Fyi, the dude can code 15 hours straight everyday for about a year (no shit thats what i saw).

Since he taught me html css javascript(even if i still suck abit at js). He made me remake the whole bootstrap in react by adding this new lib styled-components and test everything(95% coverage :)).

He also taught me webpack and rollup. Json schma forms，http requests redux， redux logic， and all the routing shit...he obliged me to i plement RR4 on release and is now making me overlook the merge requests of my other collegue (yes he made me a git pro，almost).

And now i have to work long distance by studying java， spring， oauth2 and start working on our api.

O yeah，and i went from microsoft to full on linux!!!

To be honest i thought i was gonna die this year. (Also have a kid on the way :)).

Devrant has been like going to the psychologist :) everytime shit hit the fan i realized every one has the same problems :)

Thanks to the community i can also now even give out nerd jokes :)

(L)Devrant

Every day.

I am a PHP developer.

Yeah, "another PHP is awful" rant... no, not really.

It's just unsuitable for some ambitious projects, just like Ruby and Python are.

First of all, DO NOT EVER use Laravel for large enterprise applications. The same goes for RoR, Django, and other ActiveRecord MVCs.

They are all neat frameworks for writing a todo app, as a better-than-wordpress flexible blogging solution, even as a custom webshop.

Beyond 50k daily users, Active Record becomes hell due to it's lazy fat querying habits. At more than a million users... *depressed sigh*.

PHP is also completely unsuitable for projects beyond 5M lines of code in my opinion. At more than 25M lines... *another depressed sigh*.

You can let your devs read Clean Code and books about architecture patterns, you can teach them about SOLID & DRY, you can write thousands of tests... it doesn't matter.

PHP is scaffolding, it's made of bamboo and rope. It's not brick or concrete. You can build quickly, but it only scales up to a certain point before it breaks in multiple places.

Eventually you run into patterns where even 100% test coverage still doesn't guarantee shit, because the real-life edge cases are just too complex and numerous.

When you're working on a multi-party invoicing system with adapters for various tax codes, or an availability/planning system working across timezones, or systems which implement geographical routefinding coupled to traffic, event & weather prediction...

PHP, Python, Ruby, etc are just missing types.

Every day I run into bugs which could have been prevented if you could use ADTs in a generic way in PHP. PHP7 has pretty good typehints, and they prevent a lot of messy behavior, but they aren't composable. There is no way to tell PHP "this method accepts a Collection of Users", or "this methods returns maybe either an Apple or a Pear, and I want to force the caller to handle both Apple/Pear and null".

Well, you could do that, but it requires a lot of custom classes and trickery, and you have to rewrite the same logic if you want to typehint a "Collection of Departments" instead of "Collection of Users" -- i.e., it's not composable.

Probably the biggest issue is that languages with a (mostly) structural type system (Haskell, Rust, even C#/JVM languages to some degree, etc) are much slower to develop in for the "startup" era of a project, so you grab a weak, quick prototyping language to get started.

Then, when you reach a more grown up phase, you wish you had a better type system at your disposal...

Client requests 100% test coverage..

someFunction();
expect(true).toBe(true);

Problem solved

On the first day of Christmas, the bossman gave to me: The fact that my new computer purchase order needs to be OKed by the CEO and I need to continue working on a 2014 Mac Mini (i5-4260U, 8 Gig RAM, GPU shot by an ESD on the case long ago) for the next year.
On the second day of Christmas, my family gave to me... a good reason to get shitfaced
On the third day of Christmas, getting shitfaced gave to me: A hangover and some urgent plastic welding job that had to be done with a soldering iron. FML, I've had a headache before breathing in pure hydro-cyano-whatthefuckyougetwhenyoumeltplastics
On the fourth day of Christmas, my team gave to me: A legacy, age-old Rails 2 project that was written by an intern and never reviewed, went to prod in 2014 and can't be changed anymore, but needs to be changed after the fact that it has zero test coverage and needs 100 % now to prevent issues and costly manual testing.
On the fifth day of Christmas, devrant gave to me: The Idea that making fun of Christmas songs to get over the sheer amount of dicks that working over the twelve days of Christmas sucks.

To be continued...

Day of the interview sr. Architect says: "We have near 100% unit test coverage in our code."

One month later when I tell him there are 0 unit tests written against 300 projects: "Yeah, I knew that was a problem."

What can you do when the people who want to hire you lie outright to your face?

Oh yeah, and not a god damned one was written using any sense of object oriented programming at all. Every single damned project is written like its on a motherfucking punchcard put together by a cs 101 student with a 2 hour fucking deadline.

I can understand if it needs some work, just tell me. Don't fucking lie to me just to get me in the door to fix a problem you know you have. JUST HAVE SOME FUCKING RESPECT FOR YOUR CANDIDATES AND DON'T FUCKING LIE TO THEM!

Off to drink some scotch and think about what it would be like to shove a finger deep enough into my nostril to hear a pop and smell popcorn before going off into that good night.

I said good day.

One of the best feelings when programming

When a bug in the coverage calculator stops you from reaching 100%...

I don't get it why there are so many people out, that think testing stupid model classes with getters and setter is needed.

Dude. There is no logic in this class ... it's pure data that gets not modified there (well except if you call the setter)

I've wasted way too much time writting useless unit test because some ppl want to masturbate on 100% code coverage 🤦🏻‍♂️

After a long time I finally reached this milestone of 100% code coverage. I often asked myself why I had to test every function, no matter how small. But this log output of 100% was worth it.

OK people, I don't need a novel written for every line of code, but PLEASE STOP trying to tell me that "yOuR coDe sHouLd bE sELf dOcUmeNtiNg aNd cOmMenTs mEaN iT's aUtoMaTiCaLLy bAd". That's a bunch of BS. I can't begin to tell you how many times I've saved my own butt by dropping a "this call can't be awaited; causes the library's internal API to throw an error" comment in my C#, or a "can't use double quotes here; doesn't work right for some reason" line in my JavaScript. Sometimes there are very good but un-obvious reasons why something was done a certain way, even though it looks like it could be done better. And don't try to tell me "the tests will catch it". Let's be realistic here, nobody has 100% test coverage on any project that's much more than "Hello World". And even if the tests DID catch it, why waste the time when you could just write a comment?

P.S.: This is not directed at anyone on here specifically. It's directed at all the devs I've met IRL and the comments I've seen on SO, who think that comments must be bad.

When people think 100% test coverage indicates your code is unbreakable..

Worst architecture I've seen?

The worst (working here) follow the academic pattern of trying to be perfect when the only measure of 'perfect' should be the user saying "Thank you" or one that no one knows about (the 'it just works' architectural pattern).

A senior developer with a masters degree in software engineering developed a class/object architecture for representing an Invoice in our system. Took almost 3 months to come up with ..

- Contained over 50 interfaces (IInvoice, IOrder, IProduct, etc. mostly just data bags)
- Abstract classes that implemented the interfaces
- Concrete classes that injected behavior via the abstract classes (constructors, Copy methods, converter functions, etc)
- Various data access (SQL server/WCF services) factories

During code reviews I kept saying this design was too complex and too brittle for the changes everyone knew were coming. The web team that would ultimately be using the framework had, at best, vague requirements. Because he had a masters degree, he knew best.

He was proud of nearly perfect academic design (almost 100% test code coverage, very nice class diagrams, lines and boxes, auto-generated documentation, etc), until the DBAs changed table relationships (1:1 turned into 1:M and M:M), field names, etc, and users changed business requirements (ex. concept of an invoice fee changed the total amount due calculation, which broke nearly everything).

That change caused a ripple affect that resulted in a major delay in the web site feature release.

By the time the developer fixed all the issues, the web team wrote their framework and hit the database directly (Dapper+simple DTOs) and his library was never used.

When you have to edit a 100+ line method but you discover that it has 0 test coverage.
Feels bad :/

Fixed a high priority bug today just prior to release. There was 100% test coverage. The tests pass both before and after the change. The product behavior is correct now where it wasn't before. Just one more reminder that test coverage does not equate to either quality or correctness. Tests are alarms (at best), and quality of tests are no better an any chunk of code. All tests have costs, but not all have value. All reasons why I am skeptical of the value of code coverage, TDD, or anything that posits that "all tests are good".

Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.

Little backstory. Starts with a question.

What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?

Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.

Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.

Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.

I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.

This started as an update to my cover story for my Linked In profile, but as I got into a groove writing it, it turned into something more, but I’m not really sure what exactly. It maybe gets a little preachy towards the end so I’m not sure if I want to use it on LI but I figure it might be appreciated here:

In my IT career of nearly 20 years, I have worked on a very wide range of projects. I have worked on everything from mobile apps (both Adroid and iOS) to eCommerce to document management to CMS. I have such a broad technical background that if I am unfamiliar with any technology, there is a very good chance I can pick it up and run with it in a very short timespan.

If you think of the value that team members add to the team as a whole in mathematical terms, you have adders and you have subtractors. I am neither. I am a multiplier. I enjoy coaching, leading and architecture, but I don’t ever want to get out of the code entirely.

For the last 9 years, I have functioned as a technical team lead on a variety of highly successful and highly productive teams. As far as team leads go, I tend to be a bit more hands on. Generally, I manage to actively develop code about 25% of the time to keep my skills sharp and have a clear understanding of my team’s codebase.

Beyond that I also like to review as much of the code coming into the codebase as practical. I do this for 3 reasons. I do this because as a team lead, I am ultimately the one responsible for the quality and stability of the codebase. This also allows me to keep a finger on the pulse of the team, so that I have a better idea of who is struggling and who is outperforming. Finally, I recognize that my way may not necessarily be the best way to do something and I am perfectly willing to admit the same. I have learned just as much if not more by reviewing the work of others than having someone else review my own.

It has been said that if you find a job you love, you’ll never work a day in your life. This describes my relationship with software development perfectly. I have known that I would be writing software in some capacity for a living since I wrote my first “hello world” program in BASIC in the third grade.

I don’t like the term programmer because it has a sense of impersonality to it. I tolerate the title Software Developer, because it’s the industry standard. Personally, I prefer Software Craftsman to any other current vernacular for those that sling code for a living.

All too often is our work compiled into binary form, both literally and figuratively. Our users take for granted the fact that an app “just works”, without thinking about the proper use of layers of abstraction and separation of concerns, Gang of Four design patterns or why an abstract class was used instead of an interface. Take a look at any mediocre app’s review distribution in the App Store. You will inevitably see an inverse bell curve. Lot’s of 4’s and 5’s and lots of (but hopefully not as many) 1’s and not much in the middle. This leads one to believe that even given the subjective nature of a 5 star scale, users still look at things in terms of either “this app works for me” or “this one doesn’t”. It’s all still 1’s and 0’s.

Even as a contributor to many open source projects myself, I’ll be the first to admit that have never sat down and cracked open the Spring Framework to truly appreciate the work that has been poured into it. Yet, when I’m in backend mode, I’m working with Spring nearly every single day.

The moniker Software Craftsman helps to convey the fact that I put my heart and soul into every line of code that I or a member of my team write. An API contract isn’t just well designed or not. Some are better designed than others. Some are better documented than others. Despite the fact that the end result of our work is literally just a bunch of 1’s and 0’s, computer science is not an exact science at all. Anyone who has ever taken 200 lines of Java code and reduced it to less than 50 lines of reactive Kotlin, anyone who has ever hit that Utopia of 100% unit test coverage in a class, or anyone who can actually read that 2-line Perl implementation of the RSA algorithm understands this simple truth. Software development is an art form. I am a Software Craftsman.

#wk171

Omg nothing is as frustrating as writing tests for a given file, that is needed to achieve 100% code coverage. Also not following TDD.

The feeling of 100% coverage.

Mmmmmmm.

So I've a little freelance project, is basically a blog. I've decided to use microservices with angular in the front end and python in the backend.

I've been about 2 weeks copy pasting code in my api because all the modules are pretty simple CRUDs that do the same thing, there is not heavy business logic or anything, just database handling.

I was really tired of copy pasting modules and his test, only changing function names and parameters, today I've this "epifany" about the inheritance and thinked about using it in my service, creating a base class and making all the other classes children of him.

Before the change my project has 220 tests (100% coverage) now I have only 40 tests (the same 100% coverage)

So, the lesson is: don't start throwing code like an idiot and start your project with some good planning

Today I read a great article on mutation tests, how to use and why they are important. It looks like a great thing, but...
I have never wrote any unit test in any of my jobs. Nobody in my workplace does that. And now it seems like 100% test coverage is not enough (I remind you, that I have 0%), they all should mutate to check if the quality of unit tests is high.
It seems that I'm left behind. I played with tests in my free time, but it seems the more you write them, the better you get at it, so I should be writing them in my job, where I code most of my time. Not only that, of course, I would also want to ensure that what I'm working on is bug-free.
Still, it will be impossible to introduce unit tests to my project, because they are novelty to the whole team and our deadlines are tight. The other thing is, we are supposed to write minimum viable product, as it is a demo for a client, and every line of code matters. Some might say that we are delusional that after we finish demo we will make things the right way.
Did any one of you have a situation like this? How did you change your boss and team's mind?

Completionists unite.

100% test coverage on a new feature? fuck yea!

In my company we are constricted to have 100% of f̶a̶k̶e̶ coverage with unit test.
Obviously the test suites are not performing and it takes more than 8 minutes to run 3335 tests.

I know that what I'm going to say is super mainstream but there is nothing comparable to the relief that comes from seeing all tests in green after you did a lot of small changes around the code on Friday.

Jonathan Burnhams
Started my career under him, learnt a lot from him....writing neat and simple code, with always 100% test coverage.
Very strict and straight forward.

Looking for "real reviews" of Udemy courses.

Who here have taken a Udemy course?

Which course did you take?

What was your opinion of it, in terms of overall quality, material coverage, interactivity (the coursework), and so forth?

Did you feel you actually learned useful things at the conclusion of it?

Had you taken a similar course through a different service? Which service and how did it compare?

There are some $10 courses at Udemy I'm considering purchasing. But there are two $100/each courses I'm highly interested in. TMI: We are a single income, single parent household of 3 with Christmas nearing and all the childrens have birthdays this month. Spring Break was apparently a very busy time for the adults of our extended family. Hence, even the $10 is hard to part with.