I thought `createClass` does/did something essentially similar to what `class` does in ES6. Not having to use a framework's custom class-creation machinery doesn't seem like a big loss to me or like it is has anything to do with functional programming.
Yep. It also had some differences in behavior. `createClass` auto-bound functions so that `this` always pointed to the component instance, and it supported mixins.
The React team now encourages functional forms of composition rather than use of mixins, so that's another reason why React.Component doesn't support them. The lack of automatic method binding has certainly been a major pain for people learning and using React, but it also means that there's no "magic" involved. The Stage 3 Class Properties syntax is the recommended way to ensure that methods are bound properly, and there's plenty of other possible solutions as well.
I just tested some things in PyCharm. It has no problem with word_word or wordWord as variable names. It's even smart enough to flag just the non-word in word_ajsjasjasa.
It will also put a squiggly under camelCaseWords in Python code by default, but that's because of PEP8 style rules, not spelling.
It sounds like the sites you've worked on didn't have enough UI complexity to make something like React necessary. Even for a relatively simple admin or dashboard type site, using a more modern framework/library will make it much easier to build and maintain.
It's true that you should think about what you're doing so you can avoid mistakes (and, as a side effect, type less), but you still end up typing quite a bit as a programmer, and you probably want to minimize the impedance mismatch while you're translating your thoughts into code.
I've seen this play out in real life with two programmers who were roughly equal in terms of thinking in abstract terms. One of them was much better at typing (and using tools in general), so their code quality was better overall. The other would get frustrated in the translation/typing stage and produce lots of sloppy and incorrect code.
That sounds nice, but it seems like most if not all work relationships are based on at least dishonesty through omission if not outright lies.
Employers rarely give a full and true picture of what it's like to work somewhere. It's mostly "everything's great" and "all the people are great" and so on. You might get a bland "we need to work on X" if you press them, but they're very unlikely to be direct about the day-to-day drudgery, dysfunction, etc.
Due to the asymmetrical power relationship of employers/employees, I can't see a real ethical problem with lying in response to a question they shouldn't be asking in the first place.
As someone who smokes occasionally, it sounds to me like you're just making excuses. In the past 10 years or so, I don't recall ever having to throw a butt on the ground. There was always an alternative.
Regarding your #4, that sounds nice and all, but that doesn't keep butts from ending up in streams and strewn all throughout the environment.
So often people will throw their butts on the sidewalk or in the street even when there's a cigarette-specific receptacle right nearby. There seems to be a cool factor there with the way people flick their butts away.
My technique is to rub out the burning part above the filter on the bottom of my shoe and then throw the filter in the next bin I see. That's just one idea; I'm sure there are many others.
It looks like the author prefers Django REST Framework (DRF) instead of Tastypie. I can't compare them on their technical merits as I've never used Tastypie, but I do know that DRF is actively developed and has some kind of backing. DRF is one of my "always on" Django packages.
Actually, I remember some years back that when I needed a REST API for a project I started with django-tastypie because back then (circa 2012) was more popular than DRF. Unfortunately, I did not have a good experience with it (too long to release a new version to support new django version) so I switched over to DRF and hasn't look back since.
I'm not really familiar with the status of django-tastypie right now but from what I see from the other comments it probably is better than tastypie.
Also please notice that I wanted to include one of each kind of package in the list since it's the actual list of packages I'm going to use when I need a feature - so there's no reason to include both DRF and tastypie (yes, django-simple-history and django-reversion were both included but as I explain in the article they have different usage models).
The one problem I have with this is that I want `mail.example.com` to always open in my work container, but `mail.example.com` redirects to `mail.google.com` and the latter is what ends up being saved, so it's not possible to assign to different Gmail accounts to different containers. I wish I could edit the URLs for sites assigned to a given container.
5a. There are some genuinely shitty people out there that don't necessarily deserve a pass just because no one is perfect and everyone makes mistakes. Dealing with such situations can be exceptionally difficult. Avoid talking shit if possible but try not to be apathetic either (for your own sake as well as others').
