Hacker Newsnew | comments | show | ask | jobs | submit | amix's comments login

Doist - http://doist.io/ - REMOTE - Senior Android Developer

We’re looking for a passionate Android developer to join our awesome team. You will be joining our 4-person team of developers, collaborating with them as well as working independently on various Android development projects. Most projects will be related to the mobile development for Todoist for Android (ranked last year by Google as one of the best apps in the Play Store!)

Required qualifications include: 2+ years of professional Android development or an impressive portfolio, experience with Android Studio, deep awareness of the Material design guidelines, familiar with Git, passion for what you do, and responsiveness and good communication (in English).

It’s a bonus if you have experience in JUnit / Espresso and/or the Gradle build system, and if you’ve contributed to open-source projects. We look forward to hearing from you!

Contact me directly at amix@doist.io if you are interested.

If you refer a developer and we hire this person we'll gift you the new MacBook (worth about $1299) - - or $1000 in cash. You are welcome to refer yourself.


I think this could be prevented by removing humans from the cockpit and let computers take over. Computers are already controlling most of the things inside an airplane. If this isn't possible, then the flight software should at least have protection against malicious pilots (this would protect against the mentally ill and also against terrorism (e.g. 9/11)). Basically, the planes could have failsafes to prevent malicious pilots from crashing them down or crashing them into things.


I think this could be prevented by removing humans from the cockpit and let computers take over.

I think we are not there yet:


tl;dr: frozen sensors put the plane on a crash course. Plane is saved by pilots completely shutting down the computer system.


The question is at what point flight software can be demonstrated to have a small fraction of the failure rate that humans have.

We could certainly have software flying a plane tomorrow if we wanted to, at the cost of failure rates several orders of magnitude higher. Humans have the capacity look around, intuit what's going on and what doesn't make sense, and work around it. Software that can detect and understand what to do when 3 things that each occur only one in 1,000 flights, happen simultaneously while 3 out of 10 of the sensor networks are down for maintenance and rare weather patterns are occurring on the route.

We have 100,000 flights per day to cover. Right now, we have lethal accidents roughly monthly, but we have contingency conditions that might plausibly cause a lethal accident a thousand times more often, conditions that are caught, troubleshooted, and successfully mitigated by a human.


Unfortunately we're about 40-50 years out before an automated flight control system can reproduce the critical activities of a well-trained human team of pilots.

But yes, we'll reach a point where the liability of having human beings fly planes vs the sophistication/reliability of an automated system will reach the point where the answer is a foregone conclusion. It's just a half-century away.


we're about 40-50 years out

More like 10-15 years.

Airliners already spend most of their life on autopilot today. Many (including the Airbus that crashed here) have auto-landing systems[1], too.

Fully autonomous passenger aircraft are being tested[2] in shared airspace since 2012.

[1] http://en.wikipedia.org/wiki/Autoland

[2] http://www.baesystems.com/magazine/BAES_051920/look-no-hands


The utility of autopilot to a pilot is comparable to that of cruise control to a driver, it takes away some of the drudgery. It is not robust enough to be unmonitored by a human. It can not make the many decisions that arise every day in aviation, such as if and how to avoid a thunderstorm.

Autoland needs ground equipment that is expensive to install and has stringent requirements on the surrounding topography that means many airports can not install it. It also takes 2 people's full attention to make the autoland happen in a consistently safe manner, it's not a case of pressing the LAND button and sitting back sipping tea. This video shows a bit of that https://www.youtube.com/watch?v=BMydKAcqKCg


It is not robust enough to be unmonitored by a human.

I'm no aviation expert, but isn't that only because the systems in civilian aircraft are decades old?

The state of the art in military drones seems to be autonomous landings on aircraft carriers[1]. The safety requirements for an Airliner are of course much higher than for an UAV, but the underlying technologies seem to be rather mature already.

[1] http://www.theverge.com/2013/7/10/4511476/autonomous-drone-f...


Landing is (as you've already noticed) the least significant reason as to why we have a human piloting team in an airplane.

If I could afford it, I would love to make a $10,000 long bet as to when we will see a major airline routinely (1/day) fly a route with > 200 passengers.

I'm saying it won't be later than 2065, but also won't be sooner than 2050.


I would take you up on that bet, and go for around 2025. Technology is progressing pretty fast in this area.


100% agree that the tactical technologies are racing forward, and it's apparent to everyone that things like self driving cars on freeways will be available within the next two-three years, and that sensor and response technologies will make a lot of the typical flying events a lot safer - takeoffs and landings are just two of them.

Where I don't think the technology is moving is on the executive level, which is where having a highly trained and knowledgeable flight crew in the plane is invaluable.

I'm guessing that any trained and qualified pilot of a large commercial airliner (which I am not), can immediately come up with 100 different scenarios for which there is no technology apparent in the next 15 years.

Put another way, in 10 years, 99.99%+ of the time, automated systems will be doing all of the actual takeoffs/flying/landing, but that 0.01% of the time is why we'll keep a flight crew in the cockpit.


Even the amount of automation we have today leads to the very real danger of pilot boredom: what do they do to keep busy when the flight is on auto for most of the trip and they are stuck in the cockpit just monitoring things? At least if they could fly the plane, they would have something to do! Imagine if your job was just to monitor the computer program itself, you'd get paid (yeh!), but not having anything to do would take a toll!

Check out:


If we automate even more, the problem just becomes worse. We could pull back on automation to keep the pilots alert, but we are increasingly relying on it to optimize resources (air space, fuel, airport take off and landing slots, and ya safety).

And...that's just it. Computers don't get bored. I suffer from some depression also (who doesn't!), but I find that my job keeps me busy enough that I can keep it in check. Imagine being a bit depressed and sitting in a cockpit doing nothing for a few hours at a time.


A comple of months ago I experienced the auto-landing system (as a passenger of course). The captain made the announcement before landing as meteorological conditions weren't that good (fog). I must admit I felt a little uneasy...and I am an engineer (maybe that's the reason :))


Ya Get rid of the persons involved...i.e. Self flying planes. It will happen eventually, it is a much easier problem than self driving cars, and there are already planes that can take off and land themselves in certain conditions.

But this isn't really a huge frequent problem, just one that gets a lot of press.


Why stop there? The best way to get rid of persons involved is not flying the passengers.

Until then, having the human pilot capable of overriding the computer is actually a good thing, see danieldk's comment. That the computers should help the humans as much as possible is indisputable, but it's a gradual and hard process to bring the real improvements.


In the long term it's ineveitable, juist like self ddiving cars are. Computers are actually very suitable for this.

Today, ya, maybe not yet, but we are definitely close. Flying is a hard job on humans, the hours suck, the job can be very monontomous. The problem isn't that the pilots are evil/bad, just that humans are unsuited to these kinds of tasks. Like driving.


This is very easy to imagine but needs quite a bit of testing. Human sensors are taken care of 16/7 approximately, not so with mechanical ones. A pilot can always say "I feel sick." A frozen sensor cannot.


Elite accountants usually get promoted into CFO positions, where they are very important and get a huge paycheck. There is a huge difference between a good and an amazing CFO.

I think 10X people exist in any area, including accounting and programming. E.g. John Carmack, Linus Torvalds, Poul-Henning Kamp. Some top accountants can be found by looking at CFO positions of huge companies.

These people are very rare tho' and most of us have probably not worked with a 10X person. Just like most of us have not played football with a "Ronaldo-level" player.


There are probably also 100X people - and they're mostly unemployable in any conventional sense. (Maybe Wolfram and Kurzweil?)

I think the bar for top talent is higher than is obvious, and it's lower than it used to be.

It's not at the level of 'smart and gets a lot of stuff done' - it's at the level of good as McCarthy and K&R and the guys (and occasionally the women) who invented coding in the 60s and 70s.

Most of them have been forgotten, but many of them had phenomenal skills - the kind of people who would work for a couple of months on a project, type in all the code on a single day, and have it work perfectly first time.

Or who would sketch out a fully functional timesharing OS for a new hardware architecture over a weekend and have it finished and working a couple of months later.

Or the small team at Xerox PARC led by Charles Thacker who decided to clone an entire DEC PDP-10 mainframe as a side project, because management wouldn't let them buy one and they wanted something nicer to code on.


The list of speakers looks fantastic! This said, I think the list lacks diversity. I think it would be great to have someone outside of SV in it (e.g. Jason Fried, Jeff Bezos etc.) One of the better Startup School talks I seen was from DHH (that presented another way of building a successful company).


But then they'd have to cover stuff like focusing on sales from the start of a business, developing a business model, and making money (from customers) ASAP.

(In case of confusion, I have my tongue in cheek ;-) These topics will surely be covered in the content somewhere if it's about building a business.)


There is a better way to do this by using bitmaps (especially bitmaps in Redis). I recommend looking at https://github.com/Doist/bitmapist


Technically HyperLogLog works on bitmaps, this library leverages this fact and uses Redis bitmaps instead of an in-memory implementation.

Although we are fans of Redis, if you implement it natively you can avoid network latency. Implementing it natively is not a problem because of the commutative nature of HyperLogLog

Further, If one is planning to use Redis it will be better to use built-in HyperLogLog datastructure provided by Redis 2.8.9 as documented here http://antirez.com/news/75


This presentation is tasteless and totally takes any seriousness that should be related to making and promoting an OpenSSL replacement. I personally can't take it seriously and I would recommend hackers to think about what image their presentation and design conveys.


When it comes to security tools, one uses a different approach to selecting your tools. At least, you do if you want to be secure. The best presentation and the prettiest website are nowhere in the selection criteria. You look at the history of the people involved, primarily. What have they done in the past? Was it believed to be secure by other researchers? Is it secure today because they have actively maintained it? Have they used good practices that allow their code to easily be audited by others? Have they welcomed feedback from other competent developers?

Using Comic Sans and bitching about the quality of another project is irrelevant in this scenario. OpenBSD project brings with it an almost two-decade history of seriousness about security that I think one would be a fool to ignore.


When Stee Jobs got kicked out of Lisa development and took over Macintosh he raised a pirate flag, sticking up a finger to the suits have a long and storied history in the business. The people that take offense at such things aren't people you want on your side anyway.


To me it conveys that they are a group of grognards that can't be bought and never mince words or use euphemisms, even if it upsets people. Precisely want you want for developers of a security library.


Do you mean the comic sans or calling the code terrible and (presumably) its developers incompetent?


I can recommend this article that explains OT really well: http://www.codecommit.com/blog/java/understanding-and-applyi...


Are there any great open-source implementations of OT? Last time I looked there were some, but the quality and popularity of them was questionable.



That guy also has a C library too. IIRC he used to work on the wave team.


(Author here)

ShareJS also supports collaboratively editing arbitrary JSON documents. Support for seeing everyone's cursors is being added at the moment - there's a sandbox kicking around here if you want to play with the prototype version: http://sharejs.org:7007/




For collaborating on general JSON documents, you ought to check out ShareJS; it is a great library.

However, for more complex tasks like rich text editing (at least richer than what markdown supports) you'll need to have an implementation tailored for the task.


Professional snooker is still very popular and the best earn millions of USD pr. year. So the situation between snooker and bowling isn't quite the same.


I like the general idea of this project. I think tho' it smells like a enterprisey Java project that's coded in JavaScript (at least by looking at the code and how things are structured).


> it smells like a enterprisey Java project

I'd hope you'd have something more constructive to say.

I'm not saying enterprisey is good, but, damn, evaluate it based on the actual design, rather than running away screaming because it uses IoC and publish/subscribe.


I am evaluating it on design and I think the design looks more like a Java codebase than a JavaScript one. I don't think this is a positive thing since you should not try to emulate Java idioms in JavaScript (or vice-versa).

A small example is usage of XML files for configuration of aliases. Very few people use XML files in the JavaScript world - - while it's almost a standard for Java projects.

In general, the more I look at the codebase the more messy it looks like. They could have built something much simpler that solves the same problem.


It has come out of enterprise focused development - there's no getting away from that. And we have enterprise customers that the toolkit has to support.

However, enterprise is in a state of convergence right now. Those that would not previously work at "Enterprise" orgnisations are providing great value there. Those that have been part of the web development community for some time will hopefully attest to that.

So, what we're trying to do with BRJS is follow that convergence; and be part of it. Some software engineering concepts traditionally associated with enterprise shouldn't be dropped simply because of this association. Similarly techniques and tools that wouldn't have been found in the enterprise shouldn't be dismissed because they don't conform to the expected stereotypes.

For example:

- encapsulation - separation of concerns - interfaces (In JavaScript: arrgghhhh!) - think contracts (function names and signatures). We've had lots of discussions about this but them continue to delivery value when building a maintainable app - services via an IoC/Dynamic Service Locator (see Angular) - PubSub - hopefully Addy Osmani and a number of other solutions have done enough to clarify why this is useful

All these ring of enterprise. But they're actually just good and simple software engineering practices.

When building large JavaScript apps it's about getting the balance right and we're hoping that as part of this open sourcing project we can do that.

One obvious thing that will still stand out as needing improvement are the deep directory structure (from Java). This is high on our list of improvements. We also only export to a WAR right now, but flat file export is also a high priority.


It was basically create by people who didn't have much JS experience so that's why it looks like Java more then JS, in fact that's why it's Java and not node. You're right it could have been much simpler. It used to be much worse.


It was created for people without JS experience, specifically Java devs that moved from back end to front end teams to write webapps. Things have since moved on and we're bringing the coding style, among other things, more inline with new practices.

The tooling itself is Java since a lot of Caplin's customers still have't adopted Node, in fact some of their ops departments are completely opposed to it, and just because it isn't written in the same language as your front end code does't mean the tooling and principles are any less valid or useful.


Don't forget the XML :) Seriously though, the project does look pretty cool.



Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact