1,713 karma · joined July 23, 2011
Of course, maybe that's exactly why the let him go. Regardless, I'm looking forward to seeing him do the same for GitLab. (Minus the firing.)
The MTA gave them a small budget (at least, relative to other MTA projects) and limited the scope to what the team could actually accomplish. The team itself was in charge of designing the system and bringing on specialists/contractors where necessary.
What's notable is that the project accomplished more in the span of a few months than what many of MTA's major contracts accomplish in years.
[1]: http://www.theatlantic.com/technology/archive/2015/11/why-do...
I guess my overall point here was that you can build a sufficiently interactive webapp without a bloated, client-side, MVC, virtualDOM, JS monstrosity. And that there are widely varying degrees of complexity to these implementations.
So, on the one hand, you have Ember, Angular, Backbone, React, etc. On the other hand you can have what I described. A very thin, very maintainable layer on top of what the browser is already doing.
That was the point.
Anyway, one other thing:
> Most browsers do retain the contents after navigation, both ways.
That's not what I meant. What I meant is that sometimes you need a button or link to take you back to the exact same form, just update the page slightly. (Add an optional field, etc. Think if you are entering an "album" and need to add a list of "tracks"). Without any JS/AJAX, that "add track" button will require a bit of finagling to not clear out the rest of the form that you've already partially filled out (but aren't ready to submit). I don't know if my example is entirely clear, but it's about enabling a certain amount of interactivity without relying on more standard JS bloat.
> why redo it with JS? To lower the load time? Then don't make the page multi-meg already, no?
I hear you, and often I let links do their full behavior, no JS magic involved.
But beyond a certain amount of interactivity, the AJAX intercept approach does add a few things beyond just load time:
* Even if your payload is very small, the HTTP round trip can make the interaction feel slow, especially if your browser has to go through the full load+render routine. Things like images and sometimes even the whole page will flicker. When all you need to do is update a very tiny portion of the page, having a thin JS layer on top of your usual link/form element can be a significant UX improvement.
* Say you have a page with a few interactive buttons/links and a form with text input. Without any AJAX, if you click a button or link (that isn't the form's submit button), it will wipe anything you had entered into the text field. Not a great experience.
* Intercept link clicks and form submissions and perform the exact same request asynchronously (AJAX)
* Wait for the server to respond with the parts of the page that need to be swapped-out (a JSON map of section IDs to plain HTML content) and, as expected, swap out those parts of the page.
This works REALLY well for, like, 80% of my use cases. With a little extra flavor functionality (such as automatic loading indicators and event listeners) I can enable like 90% of interactivity. The remaining 10% consists of things that affect only temporary state and don't require a server round-trip (e.g. a "select all" checkbox), and those I would handle with more traditional jQuery DOM manipulation.
For the most part, once I had this basic system in place, I could rely on the server to render (and re-render) all of the HTML and rarely had to write any custom Javascript. I was essentially relying on the behavior of vanilla links and forms. The site would even continue to function if you disabled Javascript, because the server would see that it wasn't AJAX and just render the whole page instead. The downside was that preserving local state (e.g. partially completed form fields) was tricky whenever I had to make a change to one of its parent containers.
Everything I learned about this approach eventually led me to appreciate what React.js is doing. I've been using it and I may not like all of its API or how heavy it feels overall, but the cycle of rendering and re-rendering different parts of the page feels very natural and is far easier to debug than most JS-heavy front-ends.
For example, when my grandmother fell ill, my family spent a lot of time visiting her. My mother, in particular, spent many days and nights there, and her biggest complaint was the complete lack of communication between shifts.
Every few hours, someone new would come into the room, read my grandmother's charts, wake my grandmother up, and ultimately misinterpret several important details. Thankfully my mother was often there to correct them and fill them in on what previous nurses/doctors had already done, but the net result was that my grandmother barely got any rest (being constantly woken for no apparent reason) and, had my mother not been there, a nurse or doctor could easily have made a critical mistake when continuing her treatment.
Another example, still the same grandmother. Even though her original condition improved (after having been rushed to a different hospital), she ended up going home with an entirely new infection which resulted in several more weeks of sickness and eventual recovery. The infection (C. Diff) is one of the leading Hospital-acquired infections and is in many cases totally preventable. It's hard to believe how many people die each year due to infections they pick up in hospitals.
Not saying that they couldn't have worked more closely with Kafka's team in the first place, but, hey, now we have two Kafkaesque log services instead of just one. Seems like a win to me.
Kickstarter does a lot of great things, but it seems that the highest profile projects never live up to their expectations, even when they are able to deliver.
I appreciate the argument that burnout is more like depression, and should be approached with the same mindset. (i.e. simply taking time off of work might not cure it.)
But that's not really a valid counterpoint. One person's ability to have a 2-year Github streak is not evidence that burnout is just "in the mind," as he puts it. It just means that he's found a particularly sustainable balance. In fact, I'd argue that he's kind of an outlier. That 2-year streak would definitely not work for everyone.
What we commonly refer to as "burnout" can also surface with very physical symptoms. Blood pressure spikes, teeth grinding, weight loss or gain, physical exhaustion, even heart attacks. Maybe these symptoms are better attributed to stress or lack of exercise, but when they are a result of overwork and, more specifically, the compulsive need to work at a certain level despite all costs, that's burnout. It's not good and should not be taken lightly.
https://zachholman.com/posts/streaks/
Personally, I find the contribution chart both motivating and frustrating. The contribution chart is enough of a signal that I try to make sure it looks healthy each week. But, at the same time, it's far from a perfect tool for assessing how productive I am, because commits come in all shapes and sizes. And like any gamified metric, it can lead to unhealthy obsessions.
Arguably anyone who falls for gamification has "a problem," to one degree or another. But if we know that certain personalities are more likely to have unhealthy obsessions with something, that's maybe a good reason to take it down, or at least lessen the focus on the "streak" and represent activity more positively without highlighting the gaps.
Cygwin is overkill unless you are trying to mimic your exact non-Windows environment, and it doesn't mix well with Windows' vanilla CMD environment. For those of us who want to be working with more Windows than UNIX, but who are used to standard coreutil commands, 1/100th the functionality of cygwin actually sounds kind of great!
Not saying that the commands need to be written in JS, but it seems like every language gets at least one coreutils implementation, so why not?
So much negativity around here. Honestly I find it pretty neat that JS has come this far.
Here's why. As a poor, unemployed student, $100 was a lot of money. Even once I had a nice job, I wasn't used to paying for services beyond very basic web hosting, and probably wouldn't have put any thought or energy into learning how to deploy and run things in the cloud. The opportunity cost was simply higher than I was used to.
BUT, because I had that $100, and because the networking class had given me a basic understanding AWS's offerings, I kept using AWS once I graduated. Because, why not? For small projects (hosted free on Heroku), $100 can go a LONG way (spent mostly on S3), and I was able to fund my side projects for about 2 years. Side projects that led to my current job as a full-stack Rails developer.
It wasn't about the actual value of that class or the AWS credits. (Looking back, $100 was dirt cheap compared to my tuition costs.) It was about the activation energy required to get a clueless student programmer familiar with the cloud and understanding what kinds of problems can be solved.
Part of the problem is that the overlap between "concepts used in technical interviews" and "practical things I would actually implement" is very small. So to take your approach, I'd have to go out of my way to implement something that, in the end, would have no utility to me.
Granted, there are developers out there who do take on really technical projects for fun. It seems like every language has at least one implementation of the GNU `coreutils`, which I'm sure requires at least some algorithm expertise. And there are, of course, jobs where the technical is really important (systems-level, research divisions, etc).
But for the most part, the types of interview questions they ask in no way correspond to the actual on-the-job requirements. I find it strange how common it is to interview web developers (or, engineers whose job will effectively be web development) as if they are C programmers.
Hard to say how much of it was platform-specific, since we only targeted 1 platform (for now). But the large majority of the code we wrote exists in React components or in related JS files, so porting it over to Android should be a matter of decoupling the parts of the code that rely on native features (i.e. camera, navigation, etc).
A lot of that work is already happening in the React Native community so I expect the cross-platform support will keep getting easier.
What's most amazing to me about React Native was how quickly we were able to go from idea to product (~3 months working only part-time) using our existing knowledge as web developers. We did have to write a few lines of Objective-C here and there, but for the most part all of the views and interactions fell together the same way a webapp would.
http://appleinsider.com/articles/16/01/18/apple-making-spars...
A lot of devs take this to mean Swift should be avoided for now.
Edit: To be clear, I don't agree with this sentiment! Swift is awesome. Just trying to clear up the parent comment's confusion!
I do actually agree with your point about compliance. It would be really cool if we had a POSIX-conformant set of shell commands written purely in JS, as an alternative to having to find and install compiled binary ports that run on our particular non-Unix systems. At least, it's an interesting idea.
Instead whenever something like this comes up, we see a bunch of grumpy systems programmers waving their fists in the air, as if C is the only language powerful enough to manipulate basic strings in the shell. Seems a bit silly to me when you think about it.
That's not to say that standards are bad and shouldn't be followed. Just that, sometimes, you really don't need a 250 page committee-designed specification to get some basic shit done.
How do you avoid the "Power User" effect that Digg (and arguably Reddit) ran into? If your most reputable users keep getting more and more reputable, eventually you have only a handful of very active users who have a majority of the voting power.
Well I guess everything is relative...
This question definitely captures more of the nuance that I felt was naggingly lacking in the original post. It's easy to justify firing someone in very black and white terms, but it's a lot harder to take such an employee and turn them into a valuable member of the team again, even though that might be the best outcome. Not saying it can always be done -- I've seen managers try for too long and fail, but I've also seen managers start making cuts at the first sign of trouble.