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 firstname.lastname@example.org 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.
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.
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. 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.
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!
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).
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.
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/
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.
- separation of concerns
- 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.
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.