young user @Mizukuro asked days ago for ways to improving his javascript skills.

I wasn't sure what to say at the moment, but then I thought of something.

Lodash is the most depended upon package in npm. 90k packages depend on it, more than double than the second most depended upon package (request with 40k).

Lodash was also created 6 years ago.

This means lodash has been heavily tested, and is production ready.

This means that reading and understanding its code will be very educational.

Also, every lodash function lives in its own file, and are usually very short.

This means it's also easy to understand the code.

You could start with one of the "is..." (eg isArray, isFunction).

The reason for such choice is that it's very easy to understand what these functions do from their name alone.

And you also get to see how a good coder deals with js types (which can be very impredictible sometines).

And to learn even more, read the test file for that function (located in tests/<original file name>.js. For the most part they are very readable and examples of very good testing code.

Here's the isFunction code
https://github.com/lodash/lodash/...

Here's the test for isFunction
https://github.com/lodash/lodash/...

The one thing you won't learn here is about es5, 6, or whatever.

Hello World!
I'm a bot made by @xzvf.
My goal is to find all active users on devRant and
collect analytics based on it.
By analytics I just mean things like:
- Total number of users.
- Number of users with x ++ or more
- Number of rants posted in a certain timeframe
- Number of users active in the last day/month/year

THIS BOT WILL NOT TRACK INDIVIDUAL USERS!
Also, it will not ++/-- anything automaticly as that is definitely against the rules.

-@xzvf

Oh no, oooooh nononono
they dont delete the branches after a pull request

232 branches? hhhhhhhhhhhhhhhhhhhno
and look at that naming

im intimidated, i dont want to work in this environment. No. NO!

1. There are 10 types of people in the world: those who understand binary, and those who don't.

2. How many programmers does it take to change a light bulb?
None. It's a hardware problem.

3. A SEO couple had twins. For the first time they were happy with duplicate content.

4. Why is it that programmers always confuse Halloween with Christmas?
Because 31 OCT = 25 DEC

5. Why do they call it hyper text?
Too much JAVA.

6. Why was the JavaScript developer sad?
Because he didn't Node how to Express himself

7. In order to understand recursion you must first understand recursion.

8. Why do Java developers wear glasses? Because they can't C#

9. What do you call 8 hobbits?
A hobbyte

10. Why did the developer go broke?
Because he used up all his cache

11. Why did the geek add body { padding-top: 1000px; } to his Facebook profile?
He wanted to keep a low profile.

12. An SEO expert walks into a bar, bars, pub, tavern, public house, Irish pub, drinks, beer, alcohol

13. I would tell you a UDP joke, but you might not get it.

14. 8 bytes walk into a bar, the bartenders asks "What will it be?"
One of them says, "Make us a double."

15. Two bytes meet. The first byte asks, "Are you ill?"
The second byte replies, "No, just feeling a bit off."

16. These two strings walk into a bar and sit down. The bartender says, "So what'll it be?"
The first string says, "I think I'll have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy~~owmc63^Dz x.xvcu"
"Please excuse my friend," the second string says, "He isn't null-terminated."

17. "Knock, knock. Who's there?"
very long pause...
"Java."

18. If you put a million monkeys on a million keyboards, one of them will eventually write a Java program. The rest of them will write Perl programs.

19. There's a band called 1023MB. They haven't had any gigs yet.

20. There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

when your code is a mess but everything work out in the end

When you have the deadline in three hours and a lot of code to finish, but you’re hungry.

Uhhhhh 😑

I am learning hibernate is it useful ?

At Once I thought ...

Just found out about JSON API: https://jsonapi.org/

In a nutshell, it's a very standardized REST API and feels very good to use. Let's see if the standard will be accepted by the market.

Hello!

One last feature and I’ll be done with a project holy fuck. I’m so fucking close just one more class and it’s done and I can move on to something I like a little more.

This was not exactly the worst work culture because the employees, it was because the upper level of the organization chart on the IT department.

I'm not quite sure how to translate the exact positions of that chart, but lets say that there is a General Manager, a couple of Area Managers (Infrastructure, Development), some Area Supervisors (2 or 3, by each area), and the grunts (that were us). Anyway, anything on the "Manager" was the source of all the toxicity on the department.

First and foremost, there was a lack of training for almost any employee. We were expected to know everything since day-1. Yes, the new employees had a (very) brief explanation about the technologies/languages were used, but they were expected to perform as a senior employee almost since the moment they cross the door. And forget about having some KT (Knowledge Transfer) sessions, they were none existent and if they existed, were only to solve a very immediate issue (now imagine what happened when someone quit*).

The general culture that they have to always say "yes" to the client/customer to almost anything without consulting to the development teams if that what was being asked to do was doable, or even feasible. And forget about doing a proper documentation about that change/development, as "that was needed yesterday and it needs to be done to be implemented tomorrow" (you know what I mean). This contributes to the previous point, as we didn't have enough time to train someone new because we had this absurd deadlines.

And because they cannot/wanted to say "NO", there were days when they came with an amount of new requirements that needed to be done and it didn't matter that we had other things to do. And the worst was that, until a couple of years (more or less), there was almost impossible to gather the correct requirements from the client/user, as they (managers) "had already" that requirement, and as they "know better" what the user wants, it was their vision what was being described on the requirements, not the users'...

And all that caused that, in a common basis, didn't have enough time to do all this stuff (mainly because the User Support) causing that we needed to do overtime, which almost always went unpaid (because a very ambiguous clause of the contract, and that we were "non-union workers"**). And this is my favorite point of this list, because, almost any overtime went unpaid, so basically we were expected to be working for free after the end of the work day (lets say, after the 17:00). Leaving "early" was almost a sin for the managers, as they always expected that we give more time to work that the indicated on the contract, and if not, they could raise a report to HR because the ambiguous clause allowed them to do it (among other childish things that they do).

Finally, the jewel of the crown, is that they never, but never acknowledge that they made a mistake. Never. That was impossible! If something failed on the things/systems/applications that they had assigned*** it was always our fault.

- "A report for the Finance Department is giving wrong information? It's the DBA's fault**** because although he manages that report, he couldn't imagine that I have an undocumented service (that runs before the creation the report) crashed because I modified a hidden and undocumented temporal table and forgot to update that service."

But, well, at least that's on the past. And although those aren't all the things that made that workplace so toxic, for me those were the most prominent ones.

-

* Well, here we I live it's very common to don't say anything about leaving the company until the very last day. Yes, I know that there are people that leave their "2-days notice", but it's not common (IMHO, of course). And yes, there are some of us that give a 1 or 2-weeks notice, but still it's not a common practice.

** I don't know how to translate this... We have a concept called "trusted employee", which is mainly used to describe any administrative employee, and that commonly is expected to give the 110% of what the contract says (unpaid overtimes, extra stuff to do, etc) and sadly it's an accepted condition (for whatever reasons). I chose "non-union workers" because in comparison with an union worker, we have less protections (besides the legal ways) regarding what I've described before. Curiously, there are also "operative workers", that doesn't belong to an union, but they have (sometimes) better protections that the administrative ones.

*** Yes, they were in charge of several systems, because they didn't trust us to handle/maintain them. And I'm sure that they still don't trust in their developers.

**** One of the managers, and the DBA are the only ones that handle some stuff (specially the one that involves "money"). The thing that allows to use the DBA as scapegoat is that such manager have more privileges and permissions than the DBA, as he was the previous DBA

I may have over delivered my service to this first customer i got.

It doesn't help that pricing was dirt cheap and i over promised in a bid to make it attractive.

But in my hurry to please the client, I've been feeling so much stress since last 24 hrs. Dealing with customers suck. I hate this.

They can be little dumb and doesn't think much before blaming you if something's not working as expected.

I hate this feeling and now i remember why my initial business model was designed such that I wouldn't have to deal with clients.

But somewhere along the way, i forgot about that. :/

I wish I could get rid of this customer.