I don't know about you, but this sensibly gives a TypeError when I did it in my console on Firefox 38. Please let this article be more dated than my firefox browser, because making NaN auto-coerce into an iterator sounds incredibly stupid.
Yeah, I was really interested too. From what I can get from playing around in the console, they (probably jashkenas and his cronies) they're using d3 to do the rendering. Since d3 has convenient map / filter / reduce chains, I assume (though have no proof), they can figure out the shape of your line by doing ye olde' rise / run calculation for each point. If your slopes gets significantly bigger at some point, you must have a S shape. They also force you draw only 1 point per x-increment, so they don't have to handle bad users drawing vertical lines.
Really cool idea, especially if you guys are going to build github for SVGs... but it looks like you guys have a bug in your process. Consider the workflow I attempted to do:
1. sign up
2. go through the little tutorial
3. get prompted to name a new project
4. do so, and it now feels broken (unresponsive)
5. navigate back to the project/:projectId page
6. click new design
7. select "blank"
8. get to a 404 page with the following url: https://inlinehq.com/projects/39653/designs/new?template_id=...
Also, the new design button is really unresponsive, please consider making that button aware if it has promises waiting to for your server to fulfill.
Yes, but these bears have very cleverly evolved the ability to seem irresistibly cute to the current master species of this planet. From personal observations, they seem to emit some sort of aura that induce people (in particular post-puberty to adult females humans who I'm trying to date) to emotionally melt down and make incomprehensible "cooing" noises. This aura increases in strength with increases in proximity to these bears, and is most pronounced in younger bears. The effect is particularly strong and can remain for several hours in the host even if bears are removed. This can and has led the host engaging in questionable (and often regrettable) activities with me she would otherwise refrain from doing.
In any case, for all their microbiome weakness, they've evolved a rather fascinating survival strategy to cope with humans so I don't think these bears will be removed by natural selection any time soon.
Cool service, OP, where/how are you hosting this, btw? I ask because some years ago I built a ruby-based service very much like it for personal use, but the monthly aws costs started getting to me (it was costing me about $40 a month to run... yes, I am that poor).
In case anyone from the core team is looking through these comments, why did you guys change up Ember's initializer API? I mean even new addon projects freshly generated by ember-cli are now hit with a deprecation warning regarding initializers. Considering all the things affected by the initializer change, it makes it extremely challenging to ride canary when literally even canon boilerplate code by the tomster (to say nothing of the 1k addons out there) is deprecated.
Coffeescript is a dialect for (mostly) people who don't like brackets (also cool but controversial features like null swallowing with ?, implicit function calls, etc.), while babel is a transpiler to take es6 down to es5. Saying one is a substitute for the other is like saying ice-cream mud-cake is a substitute for steak and lobster at a restaurant - if it's Saturday night and or your cheat day, just eat both. That is, pipe the output of your coffeescript into the input of your es6 babel in your build step.
I personally use a ton of emberjs with ember-cli, and ember-cli-coffeescript actually just straight-up ships this build pipeline for you when you decide to use coffee.
P.S.: Sorry if I sound like Marie Antoinette saying "let them eat cake", yes, I realize I am lucky to not have tons of legacy code that prevents me from altering my build step, and that there are thousands of other less-lucky engineers who are stuck with build systems that are essentially unalterable voodoo.
The author makes some good points about hiring and working, but what's with this fixation on diversity? If you're a small start up (i.e. 5 or 10 people in his words), your goal should be to build a product and get it to market. And if you happen to be a 30s something white male workaholic who knows a few other 30s something white male workaholics who will work with you to get it out, why shouldn't you just throw diversity out the window and work with what you have to get a project to completion.
Can someone please explain why one prefers unit testing to integration / acceptance testing when you're a seed stage company? I mean, your primary objective as an early stage company should be getting an operational product out to the market, so it makes sense that you test that your users can operate your product - aka integration / acceptance test with crapybara or phantomjs. On the other hand, if you're just unit testing you're bound to miss the bigger picture (usually this shows up in the form of misspellings in your html views, some CSRP bullshit, external apis misbehaving, etc.), and will wind up with all tests that pass but a product that still doesn't work.
Please don't generalize one dude's experience / article to all of America's universities. Plenty of professors across plenty of fields enjoy "triggering" student's visceral reactions to shocking events, new ideas, and homeworkian brutality. And the majority of students walk away from these experience with having opened their eyes and learned something without having to feel she was triggered and made to feel unsafe reading a 1000+ year old book in a classroom with plenty of adult supervision....
As for us, folks who are not in an American college for whatever reason (graduated, not in the US, underaged, etc.), judging the American university from sensationalist articles from the media to be a hotbed for either overarching protectionism or flagrant rapey patriarchy is just jumping to conclusions on our part.
Hiring managers, big companies, and schools aside, how do you tell for yourself if you yourself are a good engineer or not? For all the metrics such as load times, conversion rates, income, bounces, etc. to measure our machines, what metrics do we have to measure our professional selves for our own personal growth? Is it how many side-projects I've shipped? How many users / downloads I have? How well I can grok complex systems? How well I can solve specific and difficult programming challenges? How many javascript frameworks I can code HelloWorld in?
If we had a choice (we don't), how do we decide if we should invest in ourselves or not?
[feature request] What about the inability to selectively serialize memory and put it into sperm / egg? I mean, I get human long term memory is probably relatively new and gene serialization is as old as time, but it would be incredibly helpful if we could serialize even a little bit of our memories and experiences into our next generation. It would avoid tons of repeat learning every generation needs to figure out (e.g. don't touch fire, don't lick electrical sockets, don't shit in your bed, reading, writing, riding a bike, monads, etc.), and allow us to focus on higher level things like cracking Navier Stokes or unlocking immortality.
Great talk OP, phoenix will probably become my go to alternative to my current hybrid rails+nodejs stack as I learn more about Elixir. But because Elixir (and Phoenix) is still rapidly changing, I find tons of stuff I've written even several months ago just sort of stops working if I don't upkeep it frequently. This is just the nature of using new things, but do you have a recommend elixir version manager you use?
I think my mileage experience with uberman is on the crappy end. I did it for 2 weeks, and toward the end, I felt I was unable to focus on anything for more than 30 seconds, and ultimately had to stop when I started seeing blood in the toilet. To this day, I have no idea if my uberman sleep schedule actually caused it or not, but seeing dark red in the water definitely scared me and correlation is one hell of a incentive to stop doing something.
Yes, totally this. Moreover, I'd like to add anonymously down-voting / reporting someone's opinion just because it's not yours is just as mean-spirited as calling someone names.
Every internet message board has its own culture with its own take on what's "right" and what's "wrong", and on HN (and reddit) the institutionally accepted way of being mean is misusing the downvoting / flagkilling system to attempt to bleep out someone else's opinion because you disagree with it and labeled it as "toxic" from your perspective.
I mean, it's one thing to downvote someone because of spam or noise (e.g. one line posts of "lolwtf" or "this is dumb"), but every time I scroll through the comments and see discussion chains of folks arguing some valid points (about say referrals and paywalls or the ever controversial issue of sexism) under a flagkilled or completely invisible down-voted-to-hell post, I think to myself "this shouldn't be how our community operates."
Yes, if your goal is to get into YC, but I would argue that, as a startup founder, your goal should be building your process and getting it to market. YC, for all positive hype they get, will not help you build your product, design your process, or give you users if you didn't have the fortitude to get it in the first place. If building a startup is driving on the highway, then getting into YC is driving 95 mph, while just doing it on your own is driving 55 mph; there are more risks and deadlines involved, and there is no guarantee you will reach your destination... But if you do, it happened really quickly and everyone else is impressed.
Doing a startup is the 21st century version of the 7th century practice of going on a religious pilgrimage. And YC is a wealthy kingdom somewhere along the way; it is neither your destination nor an absolutely necessary via-point (though it is refreshing to go there). Your startup is your journey, the roads you trailblazed is your business, and the journey itself starts with you and it ends with you. YC might help you on your way, but it won't and can't carry you (incidentally, the only thing that gets your through your worst moments is blind and obstinate faith, which is surprising because this hasn't changed despite all the centuries)
I like how the first three or so anti-patterns are in the exact opposite direction as the last three or so. The art of being a programmer is literally "don't waste time over-thinking things, but also don't ship under-thought trash". For all our fixation on simplistic and ease of use, programming is actually incredibly difficult and way more art than science.
And it's exactly this requirement of masterful manipulation of balance that makes me love this field so much and long to get better at it. Getting a handle on the artsy spirit of programming is really what separates the wheat from the chaff in terms of programmer skill. There is no formal programmer guild in real life, but if there was, and there was some sort of test a journey-man programmer must undergo in order to become a master programmer, it would be the test of being given a large project and then deciding correctly exactly how much technical debt to take on to be able to ship a product within a reasonable time-frame and yet have its internals not be complete unmanageable spaghetti.
The term feminisation as used in the article title is actually not what you think it is. I'm not in your head, but I would guess you're associating feminisation with being nicer, less aggressive, less violent, less hateful, more loving, more caring, prettier, and other such positive things (which incidentally are more associated with oxytocin than the xenoestrogens, bpas, and whatnot that they're talking about), but here, feminisation strictly means a hormonal imbalance.
You can argue the accuracy and the validity of the science all you want, but the observed effects of this so-called "feminisation" is penis-related birth defects for boys and earlier puberty + menopause for girls. You are, of course, entitled to your own opinions and views on this matter, but as a man, I personally would prefer to have as large and functional penis as naturally possible.
Whoa, the closure-based circular reference memory leak thing, is that just an IE issue or is that a language level (anti) feature? I need to know because I've very often done something like:
This is literally throwing the baby out with the bath water. If we couldn't depend on other products to make our own product, then the computer industry is pretty much dead and we'll all have to go back to farming the land (and, if you're in SoCal like me, even then you'll have to depend on the mercy of our northern neighbors for water).
I think what you mean to say is "don't build a product that depends on LinkedIn", and to that, I absolutely agree. LinkedIn, with its chain email spamming and forced mass invites, is literally the post-child for internet dark patterns and unethical behavior. Furthermore, the sheer volume of people on there automatically force recruiting agencies to use bots (or at least copy-and-paste) to spam folks on there, and in general leads to bad returns for the recruiter and tons of spam for you the programmer.
I'm not married, but I take dance lessons at a local community college. There are literally tons of young girls there (especially if you can man-up and do ballet). And, because it's a community college, they're generally in their 20s so there is very little threat of breaking the law on a high schooler. If you can, try to put aside your engineer's "intellectual superiority" for a moment and talk to them as simply another person, the experience can be very fruitful.
Because folks feel there is a need for them, and it's a really good way to get one's feet wet in the compiler pound. Besides, a programming language (dialect) is to a programmer what different size wenches, pipes, or hoes are to a plumber. You need different tools for different jobs and a lot of it depends on your personal preference and what it will take you to be efficient. Besides, how we as engineers solve problems is just as much an expression of our personality as it is a statement about the correct operation of systems. But that's just my view, and I'm definitely biased on the subject because I'm working on a flavor of coffeescript that will compile to msft's typescript as we speak (well, in my spare time).
Maybe it's just me, but I find work to only suck when there is a long commute time and it's 2015 and our stupid company is still running Ruby 1.8 on rails 2.3, there is no automated testing, the javascript is an unreadable pile or .rjs mess, and literally every bug is some variant of "undefined is not a function" happening at run-time (for which I get yelled at).
In other words, work sucks primarily because it has been made to suck by a combination of extremely expensive real-estate in a down-town office and inattention toward the subject of how to make work fun.
The article calls this "the realities of work" and that the inherent difficulties and uncertainties are natural to the problems of the "real world" and must be accepted. But I beg to differ, there are tons of games that are extremely hard to play well (e.g. Sim City, Devil May Cry, etc.), yet still incredibly fun and addictive. And if you consider online games where interacting with other player can produce just as much uncertainty as real life, games are no less "real" than reality... yet they are fun while real work isn't.
Personally, I think corporations can take a page from video game design and analyze their own employees work flows and design it to be a more fun process.
Exactly this (though OP's article touches on this too). All the BS about category theory, lambdas calculus, and "logic" aside, DHH was absolutely right when he said building large software systems is much closer to writing a novel than anything science or math. Because of this inherent creative art nature, programming often depends on divine inspiration (for lack of a better term) - sometimes you sit down, and immediately see how all the workflows and data-structures, sometimes you can beat you head against a screen for months and wind up refactoring half of it.
In my opinion, the best way to tell if you are cut out to be a great programmer or not is whether you can finish and publish a project or not. Sorting algos, typing speed, functional programming, monads, es7-await, and all that jazz that interviewers like to look for can all be learned (and, comparatively, they are easy to learn), and even if you learn them, it won't make you a good programmer if you can't build extremely complex and yet detailed systems in your head.
So what about when you're just starting out, OP? When you haven't quite reached the Torvaldian heights of subject expertise in a niche, but you are somewhat competent with everything. What's the best strategy for finding / choosing gigs and building your brand then? Also, how long did it take you to reach expertise in your niche area?
Yes, absolutely this. And I'd like to add that one should also practice sickness prevention in addition to health problem fixing. Just like you'd like to avoid writing imperative spaghetti code in programming, it's also a good idea to not live a "spaghetti" life-style. That is, avoid the urge to frequently overwork and under-sleep, the sedimentary life-style of excess food/drink and insufficient exercise, and the constant self-applied pressure that you have to be better than someone else right now. Instead, go for a balanced life of work and rest, plenty of exercise, and trust yourself that you're going at a good pace and all good things take time.
Also, avoid being caught in modern media's constant drive toward polarizing sensationalism; your own life is actually fair simpler and more enjoyable than the internet and TV would have you believe (if you live in the first world)
Actually, the finance sector has this figured out better than most other sectors imo (just consider how much bonus they pay even their lowly analysts after working them to death). A good boss / company there ought to be more about earning money than having money, and so should spare no expenses rewarding employees who bring a lot of value to the corporation... So my point is you want an employer who has the character to reward everyone in the company (including him/herself) based upon some open and fair system of value contributed / need without being prompted, rather than someone who will pay you what he can get away paying you.
But deciding that most inner quality of character is difficult (since it's an hidden attribute on people), so it makes sense to look for various outward expressions of that hidden trait... one of which I postulate to be the question of whether your boss is in it for money, or in it for a vision. In the finance sector, where it's only about money, my postulate admittedly breaks down.
Seriously, unless you're deeply passionate about the vision of the company you're working for, it's super important to keep tabs on the market and leave companies that are (for lack of a better term) taking advantage of you. Unscrupulous employers, especially traditional scrooge-mcduck-business-entrepreneurs, will try to squeeze you as hard as they can while paying you as little as they can (a good rule of thumb for spotting these men and women is that they're in their business just to make money, not to chase some "nobler" vision). So it's critical that you get out as soon as you can not only because it'll be better for your financial and emotional well-being, but also so that you don't lower the market wage average of your profession and wind up hurting all the other people in your industry.