JangoSteve

Without necessarily commenting on the overall conclusions, I have a hard time feeling like I'm being well informed when certain stats seem like they're trying to cover something up (and if they're not, then maybe just show the transparent stats instead of trying to pretty them up):

> Between 1988 and 2011 the incomes of the poorest 10 percent increased by just $65 per person, while the incomes of the richest 1 percent grew by $11,800 per person – 182 times as much.

Can someone explain the relevance of comparing the bottom 10% with the top 1% instead of the top and bottom 1% or the top and bottom 10%? It makes sense to me, purely from a statistical likelihood that the growth would be a lot higher for the top 1% than from the top 10% due to the smaller selected sample size.

> Contrary to popular belief, many of the super-rich are not ‘self-made’. Oxfam analysis shows over half the world’s billionaires either inherited their wealth or accumulated it through industries which are prone to corruption and cronyism.

It's hard to tell what the actual break-down is of the world's billionaires when they lump together those who inherited their wealth and those who accumulated it through industries prone to corruption and cronyism. It seems like it'd be easier to prove the point that someone is not self-made if they inherited their wealth (versus trying to convince someone that a given industry is so prone to corruption and cronyism that the billionaire can't be considered to be "self-made").

But for all I know, only 1% of them inherited their wealth and the other >49% accumulated it through corrupt industries. I'm sure that's not the case, but you can't tell that from their article, since it lumps them in together for an aggregate statistic. And it feels like they're trying to gloss over the detail of how corrupt an industry may be, by lumping it in with the inherited wealth and thus lending some of the credibility of the argument of inherited wealth not being self-made to the argument of wealth accumulation in corrupt industries not being self-made.

I'm not really saying anything about the conclusion itself, but regardless of the argument, it's difficult to share articles with others when they contain misleading or at least flawed statistics like this.

I've found the same outlet in racing cars, soccer, and working out. I've actually told people before that I think the reason racing helps so much is that you are absolutely 100% focused on the task at hand when you're being the wheel, which means no work or personal stress at all for the time you're on the track.

Soccer is one of the few things I do that allows me to interact with people in a completely different professional field.

And working out gives me a sense of accomplishment completely divorced from my career, which I can carry with me all day in the way I feel physically.

All of these help provide context to my life (and reality), which I think helps me deal with stress at work. Another outlet my dad once suggested was reading fiction as a way to remind yourself there's more to the world than your world and to keep things in context.

Some ask how you have time for these activities with work. I ask how you can work without these activities.

Edit: Formatting and expansion.

I thought the same thing. It was a bit more subtle for me, but it prompted me to draw a sun, and when I first started drawing, it said "I see circle" but kept guessing, and with a few more lines it concluded, "I know, it's sun". Then a few drawings later I got circle, and in one second it said, "I know, it's circle".

At first I was thinking, how could it know this is a circle, but for the sun, it knew circle wasn't it when I had only drawn a circle. But it just occurred to me that the program probably tells it whether or not it's right before it actually verbalizes the guess/answer.

Then a few drawings after that, I got bus, and it guessed school-bus about 15 seconds in, and it wasn't until 10 seconds after that when it finally guessed just bus. So, I'm guessing this is the same for yours, it was simply guessing police car before car (probably because the NN takes probability into account and has gotten that as a right answer more often or something), and in your case it just happened to be right so it stopped guessing before it tried just "car."

Thanks!

The simplest one that I also use the most is start.sh: https://github.com/JangoSteve/start

I've been using it for 3 years now, but keep forgetting to tell anyone about it. It's a simple bash script that detects what kind of project your current directory is and runs the appropriate command to start the development server.

I created it, because I found myself constantly switching between projects of different types, and it always took me a few moments to remember if the current project was Rails 2 or Rails 3/4, Node, Jekyll, Rack app, etc. and starting the development server on port 3000 was starting to take 2 or 3 tries before getting it right.

Now, I just cd into any project and run `start`. It currently detects Foreman projects, Rails (old and new), Jekyll (old and new), Gollum, plain Rack apps, and Node; and it's easy to add new things as well.

Also, if we're including cost of a data plan for the phone, I think it's only fair to include gas and maintenance in the cost of the car.

Yep, that's what pretty much all genomic discoveries are these days. Since the Human Genome Project [1], which set out to map all genes in the human genome, was considered complete in 2003, most studies these days seek to find the correlations between genetic mutations and diseases.

[1] https://en.m.wikipedia.org/wiki/Human_Genome_Project

Also, the BAM file isn't really the raw file that comes out of the sequencers, that would be FASTA or FASTQ. The BAM file is then, as you stated, what you get after comparing/aligning it to another sequence such as the human reference genome.

I grew up in Wilmington. Didn't expect to see something on Hacker News from there. That's...cool.

Honestly, it's not far off from a typical CTO role. Being CTO is about connecting the technology side of the company with the vision and business goals of the company, and making sure the two match. There are great ways to structure the technology and build out the product that don't contribute to the business goals or even the vision of the startup (and can even be opposed to it), and there are sometimes less-than-ideal ways of building the technology of a company that get it where it needs to be when it needs to be there.

The CTO's job is about half technology and half business when it's a small startup. As the startup grows, you can't possibly make every technology decision, and so your job is more about getting the right people in place who can make the best technology decisions on your behalf as long as you keep them appraised of what the business needs are driving each of their decisions. And because getting those people in place and managing those people is almost all on the business side, your role becomes more about active business management while maintaining an in-depth awareness of the technology so that you can step in and correct course as necessary.

These are all just generalizations of course, as every startup is different. I imagine if you're the CTO of a startup that caters to software developers and code, you probably get to continue devoting some portion of your time to coding. Even in other startups, I've seen a lot of CTO's (myself included) get to actually do some code occasionally, but it's more like once every 1 to 3 months, which sounds about in line with what you're doing.

I think the CTO role you desire does exist, but it's in a specific, somewhat narrow stage for a startup. It sounds like you desire to be a co-founding CTO of a very early-stage (possibly idea-stage) startup. I think your desired traits for the responsibilities of a CTO can also continue to exist years into a startup's operations if the startup remains bootstrapped and self-funded.

From my experience (both with bootstrapped and venture funded startups), when a startup takes venture funding and forms a board, the CTO role becomes more about managing expectations, facilitating understanding of the technology to the depth needed to those who need to understand it to make the proper business decisions, and more importantly, contributing to and making the business decisions that require the knowledge of the technology that only you bring to the leadership and management team. The smae change in responsibilities happens to bootstrapped startups that become big enough, but the change is more organic and occurs over a longer period of time (which actually makes sense when you consider that venture funding is intended to make non-organic growth occur over a faster timeframe).

More cynically, I guess this management of expectations and facilitation of communication could be described as "dealing with everyone's crap," but really, it's probably what the startup needs. If you truly think it's not what the startup needs, then speak up! You are the CTO after all, and that's now part of your job to make sure the company is making progress. But recognize that the business side of a startup is as important (often more important depending on what the startup does, how it's funded, what it's milestones are, etc.) as the technology side, so make sure you understand the importance and motivations of what everyone else is trying to accomplish in the company before dismissing their actions wholesale.

No piece of code is written perfectly the first time. A software application (web or otherwise) tends to be a bundle of validations and compromises when written under the constraints of budgets, deadlines, and priorities.

There are many scenarios where a page used 20 times a day takes 8 seconds to load. For example, an admin dashboard page that shows some statistics on some aspect of customer usage written early on in a startup's life might only need to be looked at once a month by one of the founders (since it app has little traction, they have bigger things to worry about than seeing statistics from an n of 3).

So, it's hammered out with inefficient queries, improper indexes, etc. (after all, we don't even have a clear enough view of actual usage yet to know what indexes or queries we should really be doing).

Time goes on, the startup picks up traction, and before you know it, it's April 15, 2016, and the application handles millions interactions a week across its users. Someone on the support team at some point in the near past realized that they should be looking at these usage statistics to help drive improvements to the interface of the application, but the page now takes 8 seconds to load, because of all the data stored in that table, and because of the inefficient queries, improper indexes, etc.

Due to the nature of the business and the aforementioned constraints of budgets, deadlines, and priorities, this person has spent the last month or so just dealing with the 8-second page load. But now, it's a priority, and someone can go in, look at the data that's actually there, and figure out the best way to refactor, optimize, and improve it.

The point is, there are many scenarios where a web app can have a page checked 20 times a day that takes 8 seconds to load without assuming it's so badly written, and it certainly has a reason to exist (after all, it is partially the success of the app and value it provides to people that has caused this issue in the first place), and it doesn't need to die, it needs to adapt.

I really like this idea for our office, but I'm afraid if instituted, it'd be perceived as just a way to ensure remote workers are butts-in-chair during the day. How useful do you think this would have been as a one-way stream (i.e. remote workers can see the office, but the office can't see the remote workers)?

The article says the acquisition is expected to close in Q2. Wouldn't it not need to be disclosed until it actually closed?

I don't think I understand. I use and develop for the modern web all day every day, and I use the back button all the time. I was thinking maybe you're referring to highly interactive interfaces that use e.g. Angular, React, et. al., but even those generally use push-state to maintain back-button functionality by synchronizing the state of the app with the browser.

Makes you wonder what part of their system might be susceptible to a payee name like lil Bobby Tables.

Just because it's difficult to handle 100% of use cases doesn't mean you can't easily solved 80% of use cases. The suggestion the parent and grandparent comments are making is simply to add a button which combines the previous year's statements (understanding that not everyone's fiscal year matches the calendar year) with all the documents that are already in a separate section named "tax documents" into a single download. More generally, they're just suggesting things like naming the file for January's statement as e.g. "2016-january-statement.pdf" instead of the same generic name as every other month's statements.

Saying that those suggestions aren't valuable or worthwhile just because 100% of use cases can't be accounted for probably isn't the best way of deciding which features should be implemented (and if it were, then it seems like most of their current features should have never been built since they rarely seem to handle even 80% of use cases).

By too little data, I didn't mean that they should have collected more data, I meant that it would be nice to see a) other changes within the drug industry from the 90s and early 2000s that may or may not have contributed plotted on the same graph (not just a single line for this one rule as if that's the only event to affect clinical trials since the 70s), and b) more clinical trial outcome data into the future. More generally, I meant that it's hard to attribute historical events conclusively to specific cause-and-effect, because we can never rewind time in order to change one variable and observer its effects.

I am definitely not using the terms as they are used professionally (and certainly not a criticism of Bayesian methods in any way).

It was an attempt to explain in more lay terms how when p-hacking is performed on some dataset, the "findings" can rarely be applied to larger (or different) datasets due to the arbitrary criteria used to reject the parts of the data that aren't conducive to the selected outcome, since the rejection criteria were sort of custom-fit to that specific dataset.

I agree with everything you said.

In case it's not totally obvious, basically...

* In 2000, a rule was passed that clinical trials must include their hypotheses (i.e. clinical outcomes) in their initial registration before the trial is conducted.

* From the graph, the number and proportion of clinical trials through NLHBI with positive outcomes (i.e. an improvement in some health condition) is far lower after 2000 than before.

It was previously easy for researchers to conduct a trial, and then find positive trends in the data to form positive outcomes by framing the data from the trial in a different manner, as if the trial were originally intended to test that positive outcome. This is a problem related to A Priori Probability, where you're essentially turning research, which could have been statistically applied to a larger population given some statistical confidence, into deductive reasoning which doesn't necessarily apply beyond the finite sample size [1] (also see @entee's comment and links for better explanation of why this is important).

This article is stating that the graph implies that, because there are fewer positive outcomes after this new rule in 2000 than before, most of the positive outcomes prior to 2000 (which likely lead to new FDA-approved drugs on the market) must have been illegitimate.

I would point out though, that at least from that graph, the last positive outcome shown prior to 2000 was in 1996, so it's not like it obviously continued right up until 2000 and then suddenly stopped. Even when that rule was imposed in 2000 (I'm not necessarily sure how the ruling was phased in), there was a 4-year gap since the last positive outcome before then, and I don't see another 4-year gap prior to that since before around 1979. I'm not saying I disagree with the article (obviously), but just that while the graphic used seems to imply a trend, it seems like more data would be needed to conclusively show that trend.

[1] http://www.investopedia.com/terms/a/apriori.asp

But if there is a minimum of 1GB RAM per server, and the plan allows for up to 2GB total, then you can literally only create two 1GB servers. I'm not sure how a limit of two equates to unlimited. I was really confused by that on the pricing page.

In addition to CloudFlare, you can also use AWS CloudFront for this. We just implemented this to get https working on our custom-domain Github Pages site [1] this week.

You first have to upload your SSL certificate to AWS IAM [2] (you only have to do this once, or you can just purchase your certificate from the AWS console now too). Then, all you have to do is create a new CloudFront distribution and point the origin to your subdomain.github.io URL and select your SSL certificate from the drop-down, then point your CNAME record to the CloudFront distribution.

[1] https://os.alfajango.com/

[2] https://bryce.fisher-fleig.org/blog/setting-up-ssl-on-aws-cl...

It's mind-boggling to think of the societal effects this will have at the nationwide level for the countries where this is so prevalent. Entire programs that will need to be increased or completely created anew to handle the amount of people affected with microcephaly.

Likewise, depending on how effective the government's urging will be, imagine being one of the few children born during those two years, having only 3 other children in your class through your entire primary and secondary education (I'm not sure what the El Salvador schooling program actually is, so these are large assumptions; but I imagine at this point, not entirely outside the realm of possibility).

I totally agree with the grandparent comment. We use SNS for a few apps, none of which are mobile apps.

If you want a high level explanation for someone, I'd describe it as Amazon Callbacks. It lets you create callbacks for any action in and across any Amazon web service, where that callback can be in the form of an HTTP post (e.g. back to your web application), email, push notification, etc.

And those links weren't very descriptive and didn't fully explain the technique, so definitely helps to add to the ecosystem.

They didn't publish any code that is non-trivial to implement (and all but 1 line of code is specific to their actual data and styling), so there wouldn't be any license to worry about. This technique has also been published before (http://elvery.net/demo/responsive-tables/#no-more-tables), so you're allowed to use the technique just as much as they are ;-)

Yup, though the different way to do it with data- attributes and no content in the stylesheet was also written about here [1] in 2012, and demo'd here [2] at the bottom of the page in the "No more tables" example.

We've been using this same technique in several projects where it seemed appropriate for the past few years and have been loving it.

[1] https://css-tricks.com/responsive-data-table-roundup/

[2] http://elvery.net/demo/responsive-tables/#no-more-tables

Ann Arbor / Detroit, MI - Alfa Jango

Looking for:

* Ruby, JavaScript, Back-end and Full-stack Developer(s)

* Project / Operations Manager

Full-time, salary with benefits - LOCAL preferred, REMOTE welcome

We build startups. We act as CTO and development team for early stage startups. We help everyone from new founders who have an idea, to startups who have already raised money and have paying customers; one of our clients even went through YCombinator.

One of our startups also just got acquired by Edmunds.com in October [1]! Several of our other startups are doing very well, and one of our developers is splitting off with their own startup, so we need to invite a couple more people into the team to help us grow.

---

We've recently grown to a team of 7, and are now looking to bring on one or two more developers, as well as a project manager (who can possibly help take on management of the company operations as well). We're a small team, so you'll have the opportunity to make a real difference with the company and our startups.

---

If working on startups and open-source [2] sounds like a lot of fun to you, then you might be a good fit :-) If you're ready to become an integral part of a startup building startups, let us know.

Check us out on our website: http://www.alfajango.com

Or reach out to us: support@alfajango.com

---

[1] http://www.edmunds.com/car-news/edmundscom-acquires-carcode-...

[2] http://os.alfajango.com/

> what percentage of them aren't satisfied with the myriad external battery cases and on-the-go-chargers available for smart phones.

Well, from the article, I'd say the answer is around 33%. Specifically, this was in the article:

> Meanwhile, consumers indicated that the new smartphone feature they were most excited about — picked by 33 percent of respondents — was "improved battery life."

Also...

> I challenge the assumption that the majority of people are asking for better batteries.

I don't think anyone said it's a majority. And this article isn't about an assumption, it's about a survey.

If your repo is private, then they'd either need a really large paid account and pay for the private fork they create of your repo, or they'd have to fork your repo as a public repo. Obviously neither is really an option.

EDIT: Unless you mean just doing this for public repos, which would work, but doesn't solve the issue of private repos.

I'm not sure what you're trying to say exactly. If it's not your experience that both sides usually want to make the deal happen when the deal is genuinely mutually beneficial, then I'd say you're probably working with the wrong people (it's amazing how many perverse incentives exist in many companies and some entire industries). I'm not saying that doesn't happen. I just prefer to avoid those types of deals if possible. In fact my point was to the effect that things are quite a bit less scary when you do avoid those types of deals.

But my experience with both big and small deals, is that there's often much more flexibility than people assume, and the only way to know how much flexibility there is, is to push back a little (not for the sake of pushing back, but if there's something that you genuinely want or that bothers you about the deal, speak up).

Also, you seem to be saying that when deals get to a size large enough to warrant participation of legal departments, that there is no flexibility. That is the opposite of true, as the only reason the legal department would be involved in the first place is to work out the "custom", or non-standard, parts of the deal. If there were zero flexibility in the deal, then everyone would just use the standard documents that already exist for that deal, fill in the blanks, and sign away.

Why do large deals often result in greater than $50k-$200k or more in legal costs though? It's because the two legal teams are actually negotiating (i.e. fleshing out and changing the terms of the deal that need to be changed).