neo2001

6:29 PM PST We have identified the root cause of the DNS resolution issues in the EU-WEST-1 Region and continue working towards resolution.

sigh

Oh yes there is :D

(Author of Gordon here)

I think the people from serverless (and apex) are doing an amazing job evangelizing about the benefits of server-less infrastructures and they have amazing projects they should be quite proud of.

Than been said, I think both projects walk different paths in order to achieve similar goals.

What is different with other approaches?

* Isolation is one of the most important things for us. Each of the stages of your application are deployed into independent Cloudformation stacks.

* We don't stream commands to the AWS api. Every single of your resources are created using CF.

* We respect the tooling of each of the runtimes so javascript, java or python developers should not get exposed to software they are not use to.

* Convention over configuration. Perhaps this is because my background is the Python/Django ecosystem, but writing 200 lines configuration files in JSON feels completely wrong to me.

* Documentation documentation documentation: Again, perhaps I've been badly educated by the Django community, but documentation and examples are (for me) the most important thing a project like this should have. That's why gordon's documentation is quite complete (I would say) and we have more than 20 example project including integrations with Slack, Telegram, Twilio... and AWS services such as Kinesis, Dynamodb, Apigateway, S3, Cloudwatch Events, Cloudwatch Scheduled Events, etc...

I think is an amazing moment to be involved in the server-less community and we'll all benefit from a thriving ecosystem like this :D

I think the people from serverless (and apex) are doing an amazing job evangelizing about the benefits of server-less infrastructures and they have an amazing project they should be quite proud of.

Than been said, I think both projects walk different paths in order to achieve similar goals.

What is different with other approaches?

* Isolation is one of the most important things for us. Each of the stages of your application are deployed into independent Cloudformation stacks.

* We don't stream commands to the AWS api. Every single of your resources are created using CF.

* We respect the tooling of each of the runtimes so javascript, java or python developers should not get exposed to software they are not use to.

* Convention over configuration. Perhaps this is because my background is the Python/Django ecosystem, but writing 200 lines configuration files in JSON feels completely wrong to me.

* Documentation documentation documentation: Again, perhaps I've been badly educated by the Django community, but documentation and examples are (for me) the most important thing a project like this should have. That's why gordon's documentation is quite complete (I would say) and we have more than 20 example project including integrations with Slack, Telegram, Twilio... and AWS services such as Kinesis, Dynamodb, Apigateway, S3, Cloudwatch Events, Cloudwatch Scheduled Events, etc...

I think is an amazing moment to be involved in the server-less community and we'll all benefit from a thriving ecosystem like this :D

(Author here)Any feedback about this project would be much appreciated! Hope this tool is useful for somebody out there!

It makes it easy to deploy Lambdas and integrate them with those services. Underneath uses CloudFormation to orchestrate it

Don't want to hijack the thread (sorry) but I've been working for the last 10 months in a tool which might be of the interest of people reading this article.

This tool will be opensource in the following weeks, but at the moment is in closed beta. I'm looking for people interested in giving it a look. If you are interested, drop me an email to me[at]jorgebastida.com and I'll invite you to the repo.

tl;dr version: Dead simple Lambda+Kinesis+Dynamodb+S3+CloudWatch+Apigateway over Cloudformation with support for Python, Javascript, Java, Go etc... Lot's of examples including Telegram, Twilio, Slack... and quite extensive documentation (which I think is the key of adoption of a technology like this).

Grabs popcorn

Contrary to the author, I think Bootstrap is not used enough! The value it adds to a company to have their own hand-craft version of a CSS grid is sub zero.

Streetlife.com | London, UK | http://streetlife.com | ONSITE

Open positions:

   * Software Engineer
   * Senior Software Engineer
   * Android Engineer
   * DevOps Engineer

We're a small team of smart, driven and determined people, based in Covent Garden. Our meetings are informal, our fridge is always full of drinks and snacks, and we're out to change the world, one community at a time. We treat our employees like adults, and trust them to work in whatever way helps them to be most productive. There are no fixed office hours, timesheets, or managers watching the clock and you can take as much or as little time off for holidays as you want.

More information: https://www.streetlife.com/jobs/

Why you need facts, when you have a great imagination like me?

Warning about not to work when they are on holidays?

1. CERN is not doing the right thing. 2. Bragging about this in their blog should make CERN be fucking ashamed.

I am the only one who thinks CERN should ask AllSIM to fuck off?

This is a brilliant feature! With some Kinesis ingest processes it would be trivial to send all your "fresh" logs to logstash for example :D

That's a pretty stupid idea. Lot's occidental businesses are (or area trying) to expand their market to china. Give it a look to this map [1], and you'll understand why China is a massive opportunity.

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

It is exciting to see go spreading that fast! Count with me!

Same here,

HTTP/1.1 307 Temporary Redirect Location: http://aws.amazon.com/s3

Ubuntu 12.04 patch ready https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5....

Streetlife.com - http://streetlife.com - London, UK

Open positions: - Software Engineer - Senior Software Engineer - iOS Engineer

Streetlife is Britain’s local social network. Our mission is to help neighbours to connect and build stronger, safer, friendlier communities. Today, over 100,000 people use Streetlife to exchange local news, events and recommendations, to make real-world connections and to get together to improve their neighbourhoods.

We’re a small team of smart, driven and determined people, based in Covent Garden. Our meetings are informal, our fridge is always full of drinks and snacks, and we’re out to change the world, one community at a time. We treat our employees like adults, and trust them to work in whatever way helps them to be most productive. There are no fixed office hours, timesheets, or managers watching the clock and you can take as much or as little time off for holidays as you want.

More information: https://www.streetlife.com/jobs/

Looks phantastic

It really depends on the nature of you application, but raw speaking... probably you'll regret using mongodb as your primary database at some point.

Are non-django field types like (postgresql hstore) going to have some love as part of these migrations? If not, a proper and standardized way to write plugins to extend it would be awesome in order to be able to migrate "nonstandard" field types.

Project page: https://github.com/jorgebastida/glue