mryan

This question is one of my favourites when interviewing front/back-end developers and sysadmins. It gives candidates the chance to talk about the part of the stack they find interesting, so I can see what they are most knowledgeable/passionate about as well as judging their overall level of background knowledge.

Social, perhaps. Showing off your collection could be a motivating factor. But gamification I'm not so sure about. IMHO the typical wine collector will not be impressed by a "bought 10 bottles" badge, or something along those lines. Keep in mind I know nothing about the wine industry though, maybe the big collectors are all big kids at heart!

Interesting writeup James, thanks for sharing. The point about talking to salespeople being "part of the fun" is interesting - it's counter-intuitive to my engineer's mind, but I can see how the sales process is actually part of the value they are paying for.

That doesn't really matter in this case - the fact that the HTML references assets that are on the OP's site is pretty conclusive proof that this is a direct copy, rather than an "inspired design" or convergent evolution.

Would you be interested in posting the numbers you used for your calculations? I appreciate it is confidential information, but I find it very difficult to believe your tax rate is 70%.

If you are in fact paying 70% of your income in taxes, I can recommend an accountant who can advise on a more efficient tax strategy.

I would prefer it if you didn't reply and call me a socialist, or complain that I am dishonest - I have no horse in this race, I am merely pointing out that if you are in fact paying 70% tax, you could save a lot of money by talking to an accountant who specialises in tax efficiency.

Yes, I agree, I was just giving an example of how an additional layer can help protect against automated attacks, even for highly-secure services like SSH.

I also agree that SSH is less likely to have flaws than most VPN software. But on a properly configured bastion host, by-passing the VPN would just put you in a position where you can attack SSH. You would still need to by-pass SSH to access production servers.

I, also, trust SSH more than any other software. But it is still worth adding an additional layer of security in front of SSH to help protect from exploits.

Let's say that, hypothetically, a 0-day exploit was discovered in SSH which allowed remote code execution. A script kiddie begins trawling the internet for publicly accessible SSH servers to attack.

Your servers allow SSH from anywhere on the internet, and are eventually discovered and exploited. Mine, which will only allow SSH connections from my VPN bastion host, are effectively invisible to the attacker and will not get exploited (by this particular script kiddie, at least).

Adding a VPN server in front of SSH won't protect you from an APT, but it will protect you from 99% of the random, automated attacks that take place.

SEEKING WORK - Amsterdam, London, Remote.

I am a sysadmin who loves to efficiently solve business problems. With a DevOps background, twelve years of sysadmin experience, and a passion for problem-solving, I am keen to help HNers achieve their goals. My main areas of expertise are:

    Scaling high traffic websites

    Designing highly-reliable applications

    Migrating to AWS (e.g. from Heroku, if you want more control over your request routing and costs)

    Server maintenance and optimisation

    Reducing the cost of existing AWS resources

I am building a business around the idea of a 'sysadmin as a service' for those people who need regular sysadmin work, yet do not have enough projects to justify hiring a full-time sysadmin. Would you like a friendly expert to work on ad hoc projects and also be available for emergency support?

If you'd like to discuss any of these services in more detail, I'd love to hear from you - mike@fadedink.co.uk

All-caps titles are not good etiquette, flagged.

I think you should explain more about the service. Going straight to a demo is good, but for a service like this the server-side implementations steps are very important.

There are a few ways of supporting remote errors pages, which are you using?

Thanks for the responses folks - it seems like a combined approach is preferable.

I'll be doing a ShowHN as soon as it is published :)

If anyone wants to make suggestions about other content you'd like to see in the book, please let me know!

This is the most interesting news I've heard from AWS in a long time. I don't mean to suggest that they have not produced any exciting news in a while, but that this is service is so exciting because it will fundamentally change how a lot of people use AWS.

Of particular interest to me is how this will affect platforms like Heroku. After the recent routing mesh debacle a number of people contacted me to discuss migrating their application from Heroku to AWS.

My Heroku -> AWS migration procedure is already pretty straightfoward:

- identify Heroku services

- write Puppet manifests to manage EC2 instances

- write CloudFormation stacks to control other aspects of the infrastructure, e.g. autoscaling and S3 buckets

- write deploy scripts so clients can continue using git-based deploys

OpsWorks is only going to make this migration easier, and will have the additional benefit of letting my clients manage more of their own infrastructure without my help. Training people to change autoscaling group configuration via a web interface is one thing, training them to update CloudFormation stacks is a little less user-friendly.

From the clients I have spoken to, the key benefits of Heroku are a) git-based deploys and b) easy scaling configuration by a web interface. All of these things are possible with AWS, albeit a little more difficult to set up - especially in the case of scaling configuration - and OpsWorks is going to close the gap even further.

If AWS can provide most of these services directly, will people still be willing to pay the Heroku premium?

There is one downside to the OpsWorks announcement, at least from my personal perspective. I'm currently writing a book on AWS System Administration, and I've almost finished the chapter describing various Puppet workflows. Like many other commenters I was undecided whether I should focus on Chef or Puppet, given their relatively similar feature set and popularity. I'm not sure if I've backed the wrong horse here and should rewrite the chapter using Chef, or if having a Puppet-perspective would be useful. Any thoughts?

> (Guess the precipitating event: "Memo to all developers: One should never, ever, ever, ever, ever mention a developer who is no longer with the firm in a commit message.")

Is the purpose here to limit the amount of material that might show up in discovery, and therefore potentially be made public?

Without drills, how would you suggest Facebook tests the response times and standards of their security teams? If you want to know how the team will react under pressure, you essentially have two options:

- make up a fake security alert

- wait until a real attack is underway

Perhaps I'm missing something, but I do not see a connection to Office Space.

If I understand correctly, you want to learn more about the processes Heroku handles on your behalf? There are a few things you could do to get more familiar with the underlying tech:

) Deploy your application to AWS instead of Heroku. This will give you more understanding of what "magic" Heroku does on your behalf. Start with EC2, then build up to Elastic Beanstalk, which is rather similar to Heroku's offering. Also learn about Elastic Load Balancers and Auto Scaling.

) Learn the Xen hypervisor if you want to know what AWS is doing under the hood.

) Cloud Application Architectures is an interesting read - http://www.amazon.com/Cloud-Application-Architectures-Applic...

) AWS System Administration will also (hopefully) be an interesting read, but I need to finish writing it first :P

If I were attempting to solve this problem I would...

) Find an African SMS gateway which offers an API to send/receive messages. You could probably make this work with an SMS to email gateway as well, although it would add some complexity.

) Build a web application which acts as a multi-group chat server, where people can join/leave groups and chat to other members of the group. If you're not familiar with the process of building a web app, this will be a lot easier than going straight for the mobile version.

) Add a REST API to this web app, and build an Android/iOS app which connects to the API.

) Add SMS support to the web app. Use control messages (e.g. "/join some_channel") to join/leave groups. Figure out how to route SMS messages to a particular group - when an SMS is received for that group, use the API to send the content to other group members.

This could be implemented with a variety of stacks - personally I would go with Django for the web app, with Redis as a backend. Redis would be great for storing group membership, and I'm sure you could do something interesting with pub/sub for the messaging component.

Yes, it would. Also, "sudo -s".

SEEKING WORK - Amsterdam, London, Remote.

I am a sysadmin who loves to efficiently solve business problems. With a DevOps background, twelve years of sysadmin experience, and a passion for problem-solving, I am keen to help HNers achieve their goals. My main areas of expertise are: Scaling high traffic websites

    Designing highly-reliable applications

    Building applications on AWS

    Server maintenance and optimisation

    Reducing the cost of existing AWS resources

    Developing prototypes and full sites in Django

Although primarily a sysadmin, I am also experienced with Django/Python development. I am building my own startup with these technologies, so I know the sort of problems startups face.

I am building a business around the idea of a 'sysadmin as a service' for those people who need regular sysadmin work, yet do not have enough projects to justify hiring a full-time sysadmin. Would you like a friendly expert to work on ad hoc projects and also be available for emergency support?

If you'd like to discuss any of these services in more detail, drop me an email - mike@fadedink.co.uk

Fashiolista - Amsterdam, NL. Python/Django developers, DevOps. Full time, on-site in our office in the center of Amsterdam.

We are a funded startup looking for Python/Django developers and sysadmins with AWS experience... or ideally someone who ticks both of these boxes. As Fashiolista is growing rapidly, we are on the lookout for new team members who can help us scale the site and keep up with our growth.

Although we are in the fashion industry, a love of fashion is not required. If you love hacking open source applications and scaling high-traffic websites, you'll fit right in. We encourage our team to work on open source projects where possible, and attempt to open source many of the components we build ourselves. We are looking for "T-shaped employees" (a la Valve) who can contribute to a number of areas in the business.

Our stack consists of, among other things: - Django - Celery - SOLR - Redis - Memcached - PostgreSQL - AWS (with heavy use of CloudFormation)

More information is available on our jobs page (http://www.fashiolista.com/jobs), you can also email me directly if you would like to discuss the role futher (email in profile).

How about "session cookies for ecommerce and other transactional style web interaction, that track users across multiple sites without their knowledge or consent"? Are these good or bad?

We can decide on a case by case basis whether any particular use of cookies is good or bad, but coming up with a generic rule to do so is fraught with difficulties.

Conveniently, AWS has just made a case study on Fashiolista's setup, which will save me a bit of typing: http://aws.amazon.com/solutions/case-studies/fashiolista/

We run PostgreSQL and use its built in streaming replication.

Deploys are handled with Fabric - this includes AWS API actions (e.g. removing instances from the ELB while updating them) as well as pushing code.

We use Puppet as our config management tool, in combination with AMIs. If you just use a vanilla AMI and do all of your configuration on boot, autoscaling takes a long time, so we use Puppet to configure instances, then make AMIs of those. We also run Puppet on boot to do some runtime configuration.

This is automated, I'm planning to put the code on github once I have cleaned it up a bit.

We operate in eu-west-1, so have thankfully been relatively unaffected by the problems in us-east. Typical pain points are lack of flexibility in ELBs and variable performance on EBS - nothing that can't be worked around.

Setting up was relatively straightforward - AWS is well-documented and easy to experiment with. We did not have Puppet in place before moving to AWS - that is one thing that would have streamlined the process greatly.

I'm currently working on a book about AWS sysadmin/devops topics - some parts of the Fashiolista infrastructure will be used to demonstrate concepts in the book, but I'm always on the lookout for interesting architectures to write about. If you are doing something interesting on AWS and think it would make a good case study, I would love to hear about it.

ETA: Oh, and CloudFormation. Lots and lots of CloudFormation. I can't stress how useful it is. Our infrastructure configuration lives in the same github repo as our code and Puppet config, and is deployed using the same Fabric process. This makes the sysadmin in me very, very happy.

> so I'm going to try to be shorter this time (no promises on whether I'll succeed):

I'm guessing not ;-)

Thanks for taking the time to write a reply. I don't usually make posts complaining about people's posts for the same reason - as you said, it makes one look like a bit of a dick - but yesterday I read a number of consecutive posts that didn't really do much but add to the general level of negativity. I appreciate the same accusation applies to my post too ;-)

I completely agree re credit cards being more useful globally than iDEAL. Although I live in hope that, one day, something slightly more secure will be the norm instead.

Cheers,

Mike

roel_v, you have attributed a few statements to digitalengineer's post that were not in fact there.

" permutation of '<country I live in X> doesn't use credit cards, I'm so much smarter than those Americans'."

He just said that he hardly ever uses credit cards, and didn't make any sweeping statements about either the Netherlands or the US.

"Yeah well apparently you fail at math, because"

I'm not sure if you are aware (perhaps it was unintentional) but your reply is agressive. This sort of baseless personal agression is not welcome at HN - it might be worth familiarizing yourself with the kind of behavior that is accepted and expected here. It seems a bit strange to react so aggressively and personally to what was a benign comment.

It seems even stranger when you consider the OP didn't even mention some of the points you are berating him with - in fact, your post reminds me of Clint Eastwood addressing an empty chair at the Republican conference last year.

Back on topic - I can't wait until there is some kind of global iDEAL system, it is so much more convenient than credit cards. I know Germany and Poland both have similar systems - hopefully the UK/US will introduce something similar too.

I'm a British expat in NL, perhaps this has been introduced in the UK since I left.

Are there any plans to allow international customers (for me, UK and Netherlands) to accept credit card payments?

Integration with Moneybookers (or similar) would enable a huge range of payment options for European freelancers, and could really help you secure your spot in the market.

If there were payment options other than PayPal, I would be signing for a premium account instead of writing this comment ;-)

Yes, although I couldn't find a good example of a license that stipulates these conditions the following wiki page might help you on your search:

http://en.wikipedia.org/wiki/Multi-licensing#Market_segregat...

Another option would be to have two separate versions of your software with slightly different features. One if free for non-commercial user or single-person companies, the other has a license that prohibits use without a (paid) license.

> Personally, if I'm making a profit (assuming that's my goal) then I could care less what you call me. I'm creating value where there was none before.

Well that's something we can certainly agree on :)

> A developer doesn't need to have skills if the developer has the resources to obtain others with the needed skills.

A person who does not have any development skills is not a developer. The ability to hire developers does not make one a developer. If I hire someone to play some Rachmaninoff for me, am I a pianist?

> For example, if you want to create an e-commerce site then there are lots of hosted services which will set one up for little to no cost.

If you rent a hosted service with an off the shelf e-commerce site that is automatically installed by your hosting provider, you are not a developer, you are someone who has instructed a hosting company to set up an e-commerce site.

Now, you don't need to have any development skills to run a successful online business, that much is true. But you do need development skills to be an actual developer.

I doubt that many European government organisations would be allowed to use a SaaS app provided by a US company, purely for data protection reasons. There are rules surrounding where personal information may be stored - due to, among other things, the USA PATRIOT act, the US is not usually an option for organisations that deal with personal info.

As I understand it, PIOPS lets you specify the maximum throughput you are willing to pay for. It has no bearing on the latency/throughput you will see below the amount of IOPS that have been provisioned - you will still see latency spikes.

To answer the question added in the edit - no, PIOPS will not improve your database performance, as far as I can tell from the available information and my own benchmarks.

SEEKING WORK - Amsterdam, London, Remote.

I am a sysadmin who loves to efficiently solve business problems. With a DevOps background, twelve years of sysadmin experience, and a passion for problem-solving, I am keen to help HNers achieve their goals.

My main areas of expertise are:

    Scaling high traffic websites

    Designing highly-reliable applications

    Building applications on AWS

    Server maintenance and optimisation

    Reducing the cost of existing AWS resources

    Developing prototypes and full sites in Django

Although primarily a sysadmin, I am also experienced with Django/Python development. I am building my own startup with these technologies, so I know the sort of problems startups face.

I am building a business around the idea of a 'sysadmin as a service' for those people who need regular sysadmin work, yet do not have enough projects to justify hiring a full-time sysadmin. Would you like a friendly expert to work on ad hoc projects and also be available for emergency support?

If you'd like to discuss any of these services in more detail, drop me an email - mike@fadedink.co.uk