bmj1

As a teenager, my dad confiscated my laptop in the run-up to exams. Unperturbed, I wrote pages & pages of BASIC by hand, though I unfortunately never got around to typing them up...

Moni (getmoni.com) - London - Visa, full time

:: iOS Developer :: Android Developer :: Linux/Devops Engineer :: PHP engineers ::

This is a great opportunity to be a part of a growing development team in a London-based mobile start-up, and work in an environment that requires collaboration, great communication skills and flexibility.

At Moni we believe in latest technologies and lean approach. Our solution revolves around a distributed API backend with UX focussed mobile and web clients. We are strong believers in lean development, outside-in testing, continuous integration and delivery; we automate virtually every aspect of our day to day and are constantly looking for improvements in these areas.

Our diverse team, based in central London, is now 24 strong and growing, we are looking for smart & ambitious people who would like to help us build something truly great. If you are engaged, critical, and always ready to propose that one idea that will make our product and systems that much better - WE WANT YOU!

We are well-funded. The founders were previously heads of Google Mobile and Yahoo! Mobile product teams and we're backed by TechStars as well as a team of smart investors & advisors who believe in our vision.

If you are up to the challenge, we’d love to hear from you. Please email Athina: athina+hn@getmoni.com and let us know why you'd like to join.

Full jobs specs Android Developer: http://playfair-capital.workable.com/jobs/31269 iOS Developer: http://playfair-capital.workable.com/jobs/31268 Linux/Devops Engineer: http://playfair-capital.workable.com/jobs/27548

When I was working in Berlin a colleague mentioned that each employee has to be within a certain distance of a window.

Apologies - but I don't have a written source - perhaps someone else can shed some light..

Oh wow - that looks terrible - will fix now!

Update: I didn't realise transparency wasn't consistent across browsers/monitors. Is it better now?

Thanks for the feedback :) - can you possibly upload a screenshot for me* so I can see the issue you're having? (It can be a little tricky with the Mailchimp template editor)

* e.g. using imgur.com

I'm hoping this one will provide quality content, hence the decision to make it curated. I do agree there is a lot of noise in this space.

I clearly need to make the link more obvious, here is an example: http://goo.gl/8GRHDm

Thanks. What specific info would you find useful/compelling?

Hi all, this is very much an MVP. The idea is to collate up-to-date conversation + best practice, and share with the community. I always wanted something like this, so figured I'd scratch my own itch.

Please do feel free to provide critical feedback :)

We've discussed this in previous threads - but for those reading for the first time - there was no UK law, Cameron circumvented the legal process entirely to introduce these filters.

Terrifying.

Background: I spent the last 2.5 years working as a product manager at another payments company. I've integrated Stripe.js in various side projects. I saw first hand what happens when you make a checkout highly customisable (dozens of options): you introduce huge complexity cost.

Here are some ways this manifests:

- longer dev cycles/increased difficulty in testing/more frequent release rollbacks

- higher merchant support costs

- harder to innovate

- a need to support dozens of legacy use-cases that only some merchants use

- harder to onboard new merchants

- more complex sales process

- inconsistent user experience for customers

- higher staff training costs/time

- impossible to optimise conversion for the majority, as each merchant is showing a different checkout.

It all starts with 1 option, but it's a slippery slope.

In summary, I think Stripe are probably taking the right approach here, and I wish them the best of luck.

This actually is a very scary way for the government to make things happen.

The democratic process is for new laws to be debated in the houses. Cameron circumvented this process quite deliberately.

Hi bambax,

Not at all - I'm just trying to keep my comments balanced. By drawing attention to the insurmountable obstacles involved in achieving Cameron's stated goal, I would hope people can draw their own conclusions.

I personally think censorship is both unworkable + immoral, but I think the HN crowd can draw their own conclusions.

Thanks Jack, I've signed up and look forward to continuing the discussion over there.

"Never attribute to malice that which is adequately explained by stupidity." (1)

As a UK citizen, I've been very disappointed by this debacle. I suspect that Cameron's heart was actually in the right place (protecting the children, etc) but he does not understand the significant number of unintended consequences that we are likely to see (and are already seeing).

I would suggest doing the following to make this workable long term:

- Centralise the list of sites categorised as obscene/pornographic/etc (why should it be different for different ISPs?)

- Make the list of these sites publicly accessible and searchable

- Ensure the list is maintained by a non-political and balanced panel (is this possible?)

- Implement a process for removal requests where a site is mis-classified and ensure that this appeal process is separate from the initial panel

- Implement KPIs on the effectiveness of the filter that take into account false positives + false negatives

- Remove any automatic categorisation based on keywords, this is too crude

- Make publicly accessible the guidelines for classification

Unfortunately, I don't expect the above to actually happen :(

1. http://en.wikipedia.org/wiki/Hanlon's_razor

apologies - well it was a damn good article :)

Excellent point - I find the long meetings aren't such a difficult thing to avoid - but certainly politics and unnecessary process have no place in a startup.

The other big lesson I learnt, the hidden cost of complexity, and importance of keeping things simple (I don't think you can get this until you meet the real world): https://news.ycombinator.com/item?id=6331082 (just submitted to HN, realised it hadn't been shared yet)

This really resonated with me, I was one of those cocky, over-achieving kids who thought I could start a company fresh out of college.

Instead, I've worked in Product for 26 months and learnt some really good skills: how to write real requirements, how to manage expectations (up and down), how to negotiate, how to measure and to focus on moving the needle, how to build a GTM plan and execute against it, how to deal with fireman issues, how to develop with a SOA, the list goes on.

And picked up a bunch of payments industry expertise along the way.

I'm still determined to start my own business, but definitely a hell-of-a-lot more confident in my chances of success.

Surprising that IOS shipped before Android given the higher market penetration of Android in developing countries coupled with Khan Academy's mission.

There's another good reason not to do this. I had a host go bust ungracefully on me a few years ago - rescuing the domain took weeks of chasing with icann...

By separating the two, you can be up and running on a new host in hours in the event your host goes dark.

Just wanted to +1 on this - this is a fairly severe offence in the UK

Thank you for posting the screenshot. A clear example of a UI anti-pattern IMO.

http://wiki.darkpatterns.org/Main_Page

Nice idea - this could be achieved by dropping a cookie.

Actually I think it does have a practical use: if I want to try out a PHP technique, maybe I'm porting a small code snippet, or I want to help a friend debug their code, but don't have a PHP environment available - this is ideal.

Good point - however they should be rounding in this context.

Looks good - 1 hiccup: the calculations aren't rounded correctly. (time: 4.10)

Rounded to 2 decimal places: 11.65600 is 11.66 not 11.65 80.4672 is 80.47 not 80.46

Sorry to be pedantic...

Yes - I almost missed that - that should be highlighted more clearly not buried in a footnote - as it undermines the impact of the research...

Flagged as this violates HN guidelines: "Please submit the original source."

You'll find that adding a long salt, unique to each password, is a far more effective protector against brute force than "hash speed".

See this: http://net.tutsplus.com/tutorials/php/understanding-hash-fun... and: http://stackoverflow.com/questions/1191112/password-hashing-...

to learn more about preventing brute-force attacks

Given Moore's law and the prevalence of botnets and cloud computing - hash speed really isn't a very strong means of defence against cracking...

Also see: http://cyberarms.wordpress.com/2010/10/21/cracking-14-charac...