schneidmaster

1) Volume -- Javascript is the most popular language right now and it's not really close [1]. Attackers typically focus their efforts on systems that offer the most potential targets.

2) The language -- Javascript has relatively few convenience features in the standard library (at least compared to ruby, which is my point of reference) so more of those features are implemented in userland (and thus imported from npm). I think this is the biggest cause of massive dependency trees -- things like left_pad simply exist natively in many other languages.

3) The ecosystem -- for whatever reason, installing floating package versions was the default for a long time; floating package versions are obviously an order of magnitude more vulnerable to an attacker publishing a malicious update.

Edit: 4) I think it's also probably true that Javascript apps are particularly susceptible to this class of vulnerability, but that doesn't necessarily mean they're less secure overall. Javascript teams tend to move quickly and stay on the cutting edge, so they install lots of packages/updates and are thus vulnerable to malicious updates. Equifax's Java app was compromised for exactly the opposite reason -- they didn't install a security update to Apache Struts for months. That class of vulnerability is far less likely to happen on a fast-moving Javascript app. It's all a tradeoff; the important takeaway is to understand the failure modes for your particular stack and be vigilant against them (which in this case means using a lockfile and doing your best to audit new packages/updates).

[1] https://insights.stackoverflow.com/survey/2018#most-popular-...

In the live talk, Sophie also discussed how Javascript classes are difficult for machines: minifiers aren't able to shorten the names of methods (because it's apparently hard to work out all the ways that the method could be invoked), and they cause stability problems with hot code reloading. So there are benefits beyond ease of use for humans.

(Also, I'm pretty fluent in Javascript and I still forget to bind event handlers all the time, which suggests to me that it's a counterintuitive pattern even if I know "how it works" on a technical level. And you either have to put a bunch of "this.handler = this.handler.bind(this)" in the constructor, or rely on class properties which are an unstable syntax feature, both of which are suboptimal.)

Not really, but a lot of that is related to how we prioritize features. We set out goals and initiatives each half-year (using Aha! internally) and ensure that the things we prioritize and build are aligned with our initiatives and will broadly benefit our customers.

Sure, here's the pricing model for the SaaS startup I work for: https://www.aha.io/product/pricing

Our Enterprise+ plan is the one for our largest enterprise customers -- the extra features are:

- Antivirus scanning for attachments

- IP access controls

- Custom tables (an advanced feature where you can create your own record schema and link the records to canonical records in our product -- for example you can create a table of "customers" and link each feature to the customers that want it)

- Account backup (obviously we do our own backups, but this feature lets you easily dump your whole account to JSON so you can do your own backups too)

- Some advanced features around managing licenses within your organization

- Our concierge service (which includes support for security/operational reviews plus some sessions to guide you in rolling out our product within your organization)

Glad you found it helpful :) I recommend following patio11 on Twitter -- this is one of his regular drums to beat, and it helps having a frequent reminder of how enterprises work and that left to your own devices you will almost always undervalue your own product.

Yeah, I agree that is a reasonable approach, particularly since it tends to align well with product development (as you add more advanced features, you can easily justify segmenting them into a new premium plan). Though I'm a proponent of having enterprise pricing (or at least "call me" pricing) at any stage -- if a large enterprise comes knocking, you need to make sure you can get enough value for you to support their scale and procurement processes.

I agree and disagree. I agree that there's not necessarily a harm to having "beta pricing" or waiting to work out your price structure until you've found some product/market fit. But I was largely responding to the "Coming soon -- business $34.90/mo" plan -- I think by the time they're ready for a business plan, they're ready to start charging "real" prices. I also think you have to be cautious with "beta pricing" because it can distort your view of the market -- the cohort who will pay $10/mo is usually drastically different than the cohort who will pay $100/mo, and it's easy to mistake the former for an indication that you've got a market fit, when you might find that the market is much different when you're charging what you actually need to grow and turn a profit.

You should charge more :) Especially for your business plan -- any service targeted at enterprises should get you bare-minimum three figures of revenue per month, and you should look for a way to make it four or five, or have it scale up for large enterprises.

There are a few reasons for this:

1) The difference between $35 a month and $250 a month is a rounding error to most enterprises -- but for you, aggregated across all your business customers, it will make it much, much easier to grow and achieve profitability.

2) It's easy to lower your prices if you receive consistent feedback that people really want your product but think it's 30% too expensive or whatever. It's very difficult to raise your prices once people are locked in at a lower monthly rate (especially if the rate is an order of magnitude lower than what you end up really needing to charge).

3) Businesses are used to paying a lot of money for software (sometimes up to seven or eight figures annually). For large enterprises, there is a counterintuitive psychological factor: they don't trust something that costs $XX a month to reliably store their data and scale to their needs, and you'll actually close more customers at $XXX or $XXXX a month.

4) Selling to enterprises is very costly -- they will (try to) run you through procurement, legal reviews, security reviews, terms of service negotiations, and a litany of other things. Your price point needs to take that cost into account -- you simply can't make a profit from large enterprises if you have to spend a few thousand dollars of time/resources getting them closed, and then you have to make it up $35 at a time.

Also, I agree with the other comment saying you shouldn't offer a free plan, especially since your product is open source and they could self-host if they really wanted it. There's an inversion of value -- free users still expect you to support them, and users in free/cheap plans are often actually the noisiest for whatever reason. If I were you, I'd charge about $25/mo for the basic feature set (maybe without the branding and with more than 50 form submissions); $99/mo for the "premium" feature set; and "call me" for enterprises (hundreds to thousands a month depending on scale and commitment).

> 25 minor accidents so far this year. Mostly Cruise.

First link I clicked (Cruise "accident" on June 22, 2018) is pretty fantastic.

https://www.dmv.ca.gov/portal/wcm/connect/81d8865f-4c99-4342...

> A Cruise autonomous vehicle ("Cruise AV"), operating in autonomous mode, was traveling westbound on El Camino Del Mar between 32nd Ave and Legion of Honor Drive. The Cruise AV was struck by a golf ball from a nearby golf course causing damage to the Cruise AV's front driver windshield. There were no injuries and police were not called.

True in general, but I don't think this one's that simple. npm made a perfectly reasonable configuration change that incidentally happened to break yarn. Hard to predict since you can't sandbox every internet service that might be unexpectedly depending on you, and arguably not really npm's problem anyway. (Much to their credit, npm jumped on the issue and contacted their CloudFlare rep to help unbreak yarn, but I don't think they're responsible to proactively anticipate things like this.)

Issue is here: https://github.com/yarnpkg/yarn/issues/5885

The problem is that npm just migrated their registry to use CloudFlare. Yarn already used CloudFlare, and had https://registry.yarnpkg.com CNAME'd to https://registry.npmjs.org. CloudFlare has a security restriction that one CloudFlare account cannot have DNS records pointing to another CloudFlare account, so npm moving to CloudFlare broke yarn's existing CNAME to npm's registry (thus breaking yarn).

I don't think there's much meaningful information to glean from this list. The package at the top is literally just a package.json that installs all the packages published by one particularly prolific npm author, it doesn't have any serious purpose. Many of the other high-ranking packages simply have put their devDependencies in their dependencies, resulting in a bunch of babel plugins and the like (a mistake to be sure, but not indicative of anything in particular about the state of npm package usage).

The documentation got substantially better in 2.0 (imo), and simplifying the configuration overall was a major initiative for 4.0. You can now start with zero config if you want to follow their defaults of putting your source in /src and built output in /dist, and they also added production/development "modes" that enable a bunch of sane defaults for each. You can still get into really complicated configuration cases depending on your project but it's definitely been on an upwards trajectory in that regard.

Sample size of 1, but I Geekbench'd my iPhone X before and after upgrade.

11.2.1: Single-Core 4137, Multi-Core 9315

11.2.2: Single-Core 4039, Multi-Core 9876

Anecdotally as well, I haven't seen a noticeable difference in performance. So your mileage may vary substantially based on what device you have.

In the US this would be 100% legal. For almost all jobs, you can fire someone for any reason (I don't like your shirt, your jokes weren't funny, it's a Tuesday) or literally no reason at all. The exceptions are few and far between - unions provide additional protection via collective bargaining agreements; you can't fire someone for being in a protected class (i.e. because of their race or gender); and you can't fire someone in retaliation for something like a wage complaint. You could almost certainly fire someone for making a video you don't like (unless they're in a union, which is very few tech employees.)

From the disclaimer at the bottom:

> This site is not intended to be an exhaustive reference, nor is it a beginner's tutorial.

My company wrote a blog post a while back with some tips for a good cover letter -- it's not specific to engineering but I think it's super helpful anyway: https://blog.aha.io/the-best-cover-letters-that-ceos-love-to...

Two key takeaways (in my opinion):

- If you care about the job, do a little bit of research about the company. What does the job posting focus on and how do you align with that? What's their engineering stack and when have you worked with those technologies? This isn't "required" (i.e. you can certainly find jobs by mass-sending the same generic intro) but investing a little time in finding out about the company goes a long way towards telling them that they should take the time to find out about you in return. I also think this helps with the question of tone -- you probably won't go wrong matching the tone of the job posting itself.

- Make it easy for them to see if they want to hire you. Include your resume and make it easy to read (a short, well-formatted PDF is great). Include a direct link to your GitHub/portfolio/etc. If you don't have any public work, just say so and give them a Cliff's notes instead -- "Most of my recent GitHub contributions are private, but for the past six months I've lead a team of four developers in developing a new widget using React, Redux, and ES6, which I see is a close match to your tech stack."

I haven't seen the sad octocat falling off a cliff before. Wonder if it's just a new error page or a different type of outage than they typically have.

In my experience, Prince is great for static HTML + CSS rendering, but its JavaScript engine is pretty lackluster -- I couldn't get it to work with rendering React components, for example. So it depends a lot on your use case and if you can server-side render everything. It's also pretty pricey[1] -- not that I mind paying for quality software but that sticker could be prohibitive for a lot of folks.

[1] https://www.princexml.com/purchase

I just went to see a general family doctor originally. I made the appointment by saying that I hadn't been in for a checkup in a while and wanted to establish a relationship with a general practitioner (for me it felt even more difficult to talk about being depressed with a random secretary). Then when I went in for the appointment I told the doctor I was there because I'd been depressed for a while and it had gotten bad enough that I wanted to see about treatment options. She was kind and professional from there, recommending me to a therapist in the practice and getting me set up with an appointment. It seems like a huge mountain from this side of things but at least from my doctor's reaction, this is hardly a rare occurrence and they know how to help you without making you feel like a burden or a crazy person or something (which is what I feared before I went in).

For me, it started with an antidepressant (escitalopram, commonly called Lexapro) and weekly visits with a therapist. The escitalopram did wonders for my particular depression. I have dysthymia (also called persistent depressive disorder, I forget which is the official name now) which means I experience ongoing, low-level daily melancholy (as opposed to clinical depression/major depression, which is much more episodic in nature -- you have weeks you just can't get out of bed or eat, and you have weeks when you're pretty much fine). So for me, escitalopram did a ton to even out my daily melancholy and limit mood swings -- I still have good and bad days but my baseline is much closer to neutral rather than consistently feeling down in the dumps.

And then as I talked to my therapist over time she uncovered symptoms of ADHD that I'd never really thought about. There's a lot of debate about whether adult-onset ADHD exists, but her perspective (which seems very accurate in my case) is that people with "adult-onset" ADHD have actually had it their entire lives as well, but they had better coping mechanisms so it wasn't diagnosed at a young age. I was always a good student, rarely got in trouble, could sit still in the classroom -- but I had a terrible time trying to focus on work, I fidget constantly, I always have multiple trains of thought in my head. I'm just also a pretty fast worker and fairly smart so I was able to be unfocused and put things off to the last second but eventually lock it in just in time to beat the deadline. My therapist administered a diagnostic test (basically a multiple choice test asking about how often I experience X, Y, and Z, and a similar test sent to a close friend to be completed separately about their perceptions of me) and it turned out that I do have ADHD. So she started me on Ritalin which has also helped me immensely. I'm able to focus and be productive on a regular basis (rather than in brief but manic spurts) and it also helps my overall mood, because I'm not constantly getting down on myself for being unable to focus on something important. (That's what it means for my ADHD/depression to be "comorbid" -- they feed into each other.)

It's worth noting that this is just my particular combination of neurodivergences and treatment plan. Different people experience success with different treatments, including various medications, ongoing/regular talk therapy, lifestyle changes, etc. But the one constant is that I've never met a single person whose life has gotten worse because they talked to someone about their mental health. It's a lifelong journey but in my experience the needle only moves in one direction and it starts with opening up to someone.

Went to my doctor for the first time about what turned out to be undiagnosed/untreated comorbid depression and ADHD. I was apprehensive and avoided it for years but it's easily been one of the best decisions I've ever made. I was losing so much time to the vicious cycle of not wanting to do anything but lay in bed, then feeling crappy that I wasn't doing anything, then trying to focus but constantly geting distracted for several hours, then feeling crappy about all of that and just wanting to go back to bed. (And obviously, I have seen enormous improvements in my overall mental health and well-being, not just productivity. But it turns out that not feeling like crap most of the time also makes you a much more productive developer.)

Thrilled to finally see ST3 out of beta, it's like Christmas in September. I've used ST3 beta for literally thousands of hours since 2013, and ST2 before that. I've tried many newer options (Atom, VSCode, etc) but nothing has come close to matching the stability, speed, and reliability. I echo the other comments that I would gladly pay far more than the $70 I spent 5 years ago.

At my current company (Aha!). Fully remote which is great for me because I'm a night owl. Interesting and technically challenging work in my favorite stack (Rails/React). We use our own product so I get to see my new code/features in front of me the next day. Great environment to learn about running a seriously profitable and successful startup from the inside. And the engineering culture is right in the sweet spot -- independent and self-directed but with brilliant colleagues available to bounce ideas when I get stuck; committed to quality but pragmatic about reality for a large codebase; forward-thinking and open to new technologies but cautious about balancing value and benefit vs. the inherent risks introduced by change.

Noticed a typo in the onboarding flow: http://i.imgur.com/qbXQHrR.png

Should probably be something like "Kozmos will add the <3 button to your browser..." or at least "Kozmos will add to your browser the <3 button..." (which sounds awkward but is grammatically correct)

Ruby on Rails if it's something that doesn't demand top-of-the-line performance. It easily makes me the most productive writing backend code/APIs and it's not really close -- so many problems that are just solved, sane conventions, etc.

Elixir/Phoenix if I need blazing speed. It's younger and a bit more of a wild west but the speed is incredible.

React for the frontend (if it's anything more than basic CRUD). Regardless, webpack for frontend assets -- I'm never going back to sprockets.

Yes, your initial summary is my understanding as well. Basically, top-level domains use fairly arbitrary domains as authoritative nameservers (in this case ns-a[1-4].io), and the company that manages all the .io registrations (101Domain) was allowing any arbitrary user to register four of the seven nameserver domains. So a malicious user could have purchased all of them and pointed ALL .io domains to any arbitrary server (for at least 4 out of 7 DNS requests).

It can't really be mitigated at the user level but it's already been mitigated by the registrar. Still though, jfc.

Aha! is always hiring quality folks to work on our Ruby on Rails and Javascript (React) application. We are fully remote (work from anywhere in North America), profitable, and we offer excellent benefits.

http://www.aha.io | email: engineering-jobs@aha.io

Aha! (http://www.aha.io) | Rails / Front End / UX | REMOTE

Aha! is looking for experienced Ruby on Rails, Javascript and front-end engineers to develop rich interactive experiences in React with a Rails backend.

Aha! is the #1 tool for product managers to plan strategy and roadmaps. Aha! is profitable, you can work from anywhere in North America and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding), we deploy continuously and we are developing in Rails/CoffeeScript/React/d3. Our entire team is remote - in US, Canada and Mexico so we can collaborate during the work day.

http://www.aha.io | email: engineering-jobs@aha.io

@SwiftOnSecurity. Excellent tweets on security, general programming stuff, nerd humor, and women in tech.