For people studying the brain, I would have hoped not to read the article in the highest contrast my screen can produce with pure white text on a pure black background. After the first two paragraphs I could see nothing but lines :(
The worst part is it looks like they wanted the text to have a nice gray shade of #666, which is OK to read on a white background, but for some reason decided that white on black is better.
For those that are interested, I posted an article[1] a little while ago on how to automate the renewal process for Letsencrypt using Daniel's acme-tiny[2] script. It's a lot nicer to let cron handle it than doing it manually ;)
Or at the Apple store! omg, the number of times I've walked in, gone directly to a sales person to request that they kindly go to the back room and retrieve a specific item for me so that I can give them money and been stalled, interrogated, and counter advised on other products when really I already know what I want and just want them to get it for me.
me: "Hi, I'd like to buy a White 13" Macbook with a 500gb HD and 8gb of RAM. Could you please get one for me?"
sales person: "What are you using it for? Do you browse the internet? look at photos? do a lot of word processing?"
me: confused "um, I do web development and use Photoshop sometimes..."
sales person: "Oh well you need a Macbook Pro then."
me: "no, I can't afford that and the regular Macbook is plenty powerful for what I need. Can I just buy one please?"
sales person: "Photoshop won't run well on the regular Macbook. What you really want it the Macbook Pro. You'll need at least 16gb of RAM and if you're editing photos you'll want a bigger harddrive, not to mention the extra power that comes from the Pro's CPU."
me: "um, I have money in my hand right here that I will give you in exchange for a regular Macbook. Can you please go get one and take my money?"
The problem is that they don't know that you actually know what you want.
You present identically to the kind of person who is completely non-technical and was mis-advised by a friend of theirs, and who will come back in a week complaining about how Photoshop doesn't run well enough and their hard drive is full.
Apple has decided that they want to ensure that you are happy with your purchase, and part of that process involves the salesperson being convinced that you are buying the right thing.
I just get frustrated being told what I want, being upsold, and being made to feel as if I don't know what I'm talking about when in fact I probably know a lot more than the sales person who has probably never used the device in question the way I've described I will be using it.
I understand that the general case is better serviced this way, but for someone who walks in knowing the part numbers they want, the added friction is a turn off.
I personally avoid going to Apple stores because of how hard it is to actually buy stuff there. Even grabbing a simple USB key off the shelf is incredibly hard to pay for when the cashiers are all hiding in a sea of other people.
> I'd think "I do web development" should be a sufficient signal that "this person is not non-technical."
Not to a systems software developer, sonny.
/s
(Besides, "I do web development" could easily mean "I know what Dreamweaver is". (It's that song by Gary Wright which helped inspire Freddy Kreuger, right?))
> (Besides, "I do web development" could easily mean "I know what Dreamweaver is".
People who fall into the (negative) category "I know what Dreamweaver is" never describe themselves as web developers, but rather as web designers (and the serious web designers, say, as UX designer).
I misread that the first time, and thought "I don't understand... someone saying that they do web development should be a perfectly clear sign that they're nontechnical, especially to a systems developer".
I agree with others that the author seems to be missing the point of React. Whether or not it is "reactive" or doing things the way you're supposed to do them is irrelevant. It's a tool, and it either helps you fix your problem, or it doesn't. IMHO React helps a lot.
I've built a few non-trivial apps with React this year (e.g., https://github.com/robmclarty/barss), and after years spent building and maintaining apps made with backbone, angular, jquery, and other libraries (considering the domain of React => the view) I can easily say that React has saved oodles of time, allowed me to greatly understand my apps as a whole much more clearly, and enabled me to think less about propping up a structure for my app and focus on actually designing my app.
The point is, it's not about what's passive or reactive or [insert enlightened path to programming here]. It's about what works; what keeps the ball rolling; what gets your app online and in front of users.
When it's snowing outside and I'm making a decision about what I should cover my feet with, I'm concerned about "what will keep my feet dry?". When I'm moving across town into a new apartment, I'm concerned with "what will have enough volume to transport all my junk?". When I'm making an app, I'm concerned with "what will make this design in my head work in a browser?". Whether I wear boots or shoes, whether I use a diesel truck or a gasoline van, or whether I use React or Whatever; that's not what's important.
I like that React doesn't drag me into event-listener hell where stuff is firing from somewhere that I don't know where. I like that React compartmentalizes templates with the behaviours that manipulate them. I like that React passively alters itself based on state changes.
When it comes down to it, an app is, simply, an interface for mutating and presenting data. It can be in one of many possible states at any given time. React just presents a view of the app that is based on its current state of data. With React, all I have to worry about, conceptually, is "what's the data?" and my app reconfigures its presentation accordingly.
TL;DR At the end of the day it doesn't matter what's right or wrong, it matters what realizes your intentions as a programmer (and as a human). The way React works makes my job easier, more productive, and faster. It doesn't suck at all.
These new rules seem reasonable and no different from what businesses are/should already be doing.
Does "consent" apply to websites which add an "opt in" checkbox but check it off by default and hope that nobody sees it?
This really irritates me and I would argue does not constitute my having given my consent to receive emails. That said, I don't see an easy way to distinguish this kind of practice from a legitimate opt-in checkbox.
Exactly. If you don't want to burden your little head with OPAs and APIs and application architectures, just stick the jQuery and happily manipulate the DOM here and there as you see fit. If you want to make something bigger, something more app-like (in your browser), something that's not merely a web page, you're going to need some structure like that found in an MVC framework.
Coming off working on a large Backbone app, I've seen how bloated, needlessly repeated, and painstakingly verbose things can get. Angular solves a lot of the problems I have with Backbone by taking care of basic plumbing for me so I can focus on the unique parts of my app. It's magical, but that's what I want in a framework: less pounding out boilerplate and more writing application code.
Don't be a used-car web dev then. Be the luxury sedan - sport car web dev. I explain to my clients (not necessarily through this analogy) that I'm definitely not the cheapest dev/designer they'll be able to find, but that they'll gain more quality, etc. for more money with me (with case studies to back that claim up). I don't sell my clients used cars, and so they don't expect to pay used-car rates with me ;)
I think we all understand that spaghetti code simply adds time to the next feature we want to introduce, probably creates unseen bugs, and might explode. But it's always a balance and nothing is black and white.
I hear a lot of "you're wrong, do it the right way first!" but you gotta balance "the right way" with its context. Code isn't made for code's sake, it's made to do something (like a business objective, like "be able to order a book through my browser"). Businesses are trying, first and foremost, to make profit, however they need to do that. Beautiful code has nothing to do with that goal, but is sometimes a means to that end.
If the code achieves the business objective it was meant to achieve, it's doing its job (however minimally). Customers don't care what the code looks like (if they look at it). They just care that it does what they need to do (like order a book). Businesses don't care what the code looks like as long as it makes profit.
Secondary to the business objective is how that code fits into the greater context of the system-as-a-whole. Obviously badly written code is going to accrue technical debt, which will likely lead to cumulative delays to new features, cause things to break, etc. The extra effort involved in dealing with that debt is obviously going to cost something, which will have an affect on the primary goal of business: profit. But also delaying a feature, to "do it right the first time", that could be earning revenue, is also going to affect profit. The key is to balance it to maximize profit overall.
When I do anything (code, draw, write, cook, paint, dance, whatever) I start by doing it the simple, easy, fast way; I probably fuck it up; then I iterate and try to improve upon it and refactor. Usually in getting something out there I discover new solutions that I would not have seen had I not actually made something and put it into the world where I could look at it and point to it and talk about it with other people. Being an early mover aside, I think this kind of process helps overall quality anyway. And in the meantime I've got something that's at least doing something.
I think Joe Armstrong knows what he's talking about ;)
I agree this is a bit of overkill for a "my first hand-coded website" project. I've been hand-writing websites for over 15 years (back when all I had was Notepad on a Windoze box). I think I'd approach this sort of learning adventure more along these lines:
1. HTML/CSS (This is the end-result a browser needs, and you can write it all by hand yourself; by not using any grid/layout frameworks you'll learn all the fun things that CSS can do for you and you can focus on making clean semantic markup without any other dynamic distractions.)
2. Do some simple backend stuff that now dynamically generates the above HTML/CSS based on some simple logic (I'm thinking PHP to start because it's on almost every server already so you don't need to worry about installing anything... just get used to the idea of generating the above static HTML with some programming logic.)
3. Add a database (probably going to want to go with MySQL for the same reason as PHP; learn how to store data in the cloud and retrieve it to show in your dynamic pages)
4. Maybe learn some server config (probably Apache) but don't get too carried away because you can do a lot before you need to be installing Apache modules and tweaking environment variables... I'd just start by playing with redirects and error pages)
5. Now that you can build a full-stack website, I'd probably beef up my graphic design skills to make that shit sparkle (Usability, information hierarchy, and clear communication are the names of the game here. Design skills can make up for many technical difficulties if you think about the business problem you're trying to solve, not just how fancy you can make your sorting algorithm)
6. With the fundamentals under your belt, now I'd start looking into frameworks and libraries and helper tools that can make all of the above easier and faster. Now you'll understand what those tools are really doing for you and where they're appropriate to pull out. Get your CSS grid, your LESS compiler, your deployment tool, your database inspector, your autocompleting IDE (if that's what you're into) and make the computer do the grunt work, but now with the understanding of how it's helping you so that you can bend it to your will.
7. Move on to more advanced stuff like front-end MVC, non-blocking backend, websockets, streaming, ssl, localstorage, scaling optimizations, etc. But now that you can do the foundation yourself, you can add-on any of these advanced techniques as needed (no one in particular is absolutely necessary as they are specialized to particular tasks).
To me, this is the sort of DIY path that should be taken, step by step, to really understand how to construct a web property. IMHO the OP jumped into the deep-end a little too early. Learn to walk before you run ;)
