AWS CodePipeline
aws.amazon.com
aws.amazon.com
But if they ever release a tool that is inspired by the Brazil build system, pack up and run for the hills. When it takes a team of devs over two years to get Python to build and run on your servers, you know your frankenstein build system is broken. It could be replaced by shell scripts and still be orders of magnitude better. Nobody deserves the horror of working with that barf sandwich.
Nix uses a pure evaluation model so it enjoys the property: An artifact in the nix store is uniquely identified by the closure used to build the artifact. For any artifacts A, B if and only if the closure used to build the artifact are equal then the artifact file path will be equal.
This creates opportunities for sharing between builds that can be hard to achieve in other systems. One form of sharing "referencing a derivation in multiple apps" works as expected, just like other systems: Each app will reference the same artifact.
(a derivation is the closure to be evaluated to build an artifact in the nix store. Well, attribute set of closures.)
Suppose a derivation is assigned to the variable "commonData" and two derivations "appX" and "appY" reference this closure. "commonData" will be built once and both app derivations will receive a path to the same file in the nix store.
The other form of sharing comes from the equality comparison being based on the closure and not the name used to reference the closure.
Ehh.. I'm butchering the explanation... I think there is a succinct PL term that covers this.
Suppose we have a derivation:
let x = mkDerviation { name = "foo"; builder = aBuilder; src = /share/src/foo; }
which is referenced by another derivation
let y = mkDerviation { name = "bar"; builder = aBuilder; src = /share/src/bar; inherit x; }
"y" will force the evaluation of the "x" derivation's closure. The source directories, since they are not in the nix store, will be copied to the nix store first. (By an implicit conversion between local files and nix store paths)
So far so good, but what happens if there is another derivation like so?
let z = mkDerviation { name = "zab"; builder = aBuilder; src = /share/src/zab; somethingLikeX = mkDerviation { name = "foo"; builder = aBuilder; src = /share/src/foo; }; }
"somethingLikeX"'s equation is equal to "x" but not the same reference.
What will happen if z is evaluated after y? (assuming aBuilder is the same) First, the derivation "somethingLikeX" will be evaluated. Ah ha! That closure is equal to the closure for "x" above! Which has already been evaluated. So that evaluation result will be shared. Even though "z" does not directly reference "x".
This can result in more sharing than the developer explicitly requested: Equal closures are shared.
http://google-engtools.blogspot.ie/2011/08/build-in-cloud-ho...
http://www.quora.com/Does-Google-consider-releasing-its-buil...
It means they don't even support their own new "Git" product AWS CodeCommit [1]
[1]https://aws.amazon.com/blogs/aws/now-available-aws-codecommi...
You’ll pay $1 per active pipeline per month (the first one is available to you at no charge as part of the AWS Free Tier). An active pipeline has at least one code change move through it during the course of a month.
Does this mean that every time you run a session you pay 1 EUR no matter how many stages the session has (pull, compile/build, test (multiple tests) and deploy?
Pipeline used 0 times - $0, 1 time - $1, 500 times - $1
Not that it matters, but I think they use GWT.
I understand their desire to create unique "products" that people can use in a conversation (e.g. "Have you considered Route53 for your DNS?"), but ultimately mixing common and niche things together and giving everything confusing names is likely doing Amazon more harm than good.
That all being said, Amazon are slowly improving. See this page[0]. They now have a list of their products and how they fit into different categories. But the console can still be a jumbled mess of different acronyms and made up words.
"I need to host a web app" "Okay there's Azure Web Apps for that"
"I need to store lots of files" "There's Azure Storage/Blob Storage for that"
"I need a SQL Database" "There's Azure SQL for that"
"I need a VM" "There's Azure Virtual Machines for that"
"I need a Data Lake" "There's Azure Data Lake for that"
"I need a Data Lake" "There's Azure Data Lake for that"
"I need a Data Warehouse" "There's Azure Data Warehouse for that"
"I need a Cache" "There's Azure Redis Cache for that"
I could go on, but you get the picture. Cute names are not the way to go when you're offering dozens of services which may overlap with eachother somewhat. I can just scroll down a list of things MS offers on Azure and be able to easily pick out the things I need to use by their names alone.
So it's just deeper down the rabbit hole.
> Not that it matters, but I think they use GWT.
the problem is I think it's much more difficult to iterate with this kind of abstractions.
This used to be the case - new features usually launched API-only and console came later - but I think Amazon has woken up to the fact that many customers want to play with it easily before they go automating everything using the API.
I've been wondering about this recently myself. It does seem to be the case sometimes. Any idea why, or if this has ever been studied?
Function ugly app - Ehhh I could research better fonts, but sans serif will work - let's go code some new featues.
An internal tool like Asgard doesn't have the same need a customer-facing tool like the AWS Console does to be user-friendly, either.
AWS just builds the basic UI's to make it possible for people to do simple things. If you get deep into the weeds, you'll need to use the API directly, i.e. for installing an SSL cert on your CloudFront distribution, or launching a 2K node computing cluster.
If you don't like the UI, make your own and sell it to people. That has become a viable business model for various startups, or launch your own hosting company on top of EC2 like Heroku.
Or ask Amazon to hire some good UI designers.
AWS is in a race to the bottom, cutting prices all the time. Hiring 50 UX devs to rewrite their web interfaces doesn't comport with Jeff's lean vision.
So again, I say, the AWS team is spamming HN and it's in poor form. It should all be one submission.
We can't make a big flat list and sort those by date without losing the threadedness of the comments and thus their context. But we could sort siblings by date at each level of the tree, including the top level. Is that what you mean?
Sometimes this would be a good thing. Top-level (and in general 'higher up the tree' comments completely dominate. It's rare for the direction of a HN thread to shift much after a reasonable number of comments as everything gets buried quite far down.
I'd really like a 'what changed since i was last here' button. Quite often I come back to a long thread I was especially interested in and I'm completely unable to find out if anything of value has been added.
> But we could sort siblings by date at each level of the tree
More options = better. The intended audience of HN can cope with a few more things to click. Treat us like power-users.
So is the lack of options to resort and reorder comments an intentional thing?
It would be interesting to hear the reasons for it and what benefits you consider it brings.
Yes, lots of us are interested in AWS (I am too), but that doesn't mean each separate announcement should be its own post. And I don't think the nearly uniform submissions we see would have happened organically.
If one or two of the stories are noticeably weaker than the others, or especially if they've appeared on HN before, we'd appreciate users pointing that out, since we can penalize those.