Terraform 0.12 - <AUTHOR> https://www.hashicorp.com/blog/announcing-terraform-0-12 <comment><USER2> I honestly love Terraform as a product. It was one of probably three tools I've used in my entire career that made me feel immediately more productive. After using it for a very short period of time I was shocked developers continued to struggle through CF templates and the fragility the whole process entailed.

<comment><USER3> this is short-sighted. Terraform and CloudFormation are not even in the same league. One of them works and actually can be used for Infrastructure as Code, the other one does not roll back in the face of failure - it effectively craps for reasons ranging from network failure, process crash, even normal operation. One is heavy kool-aid with bugs that go unresolved for years, the other behaves as advertised.

Sorry, but I have yet to meet a developer that used Terraform and willingly wants to keep using it after seeing it fail. When your tool cannot keep track of the resources it created or when it gets into situations where it doesn't allow you to do certain things (like deleting all resources created) and you have to relearn how the underlying cloud works, it's time to move on.

Do yourselves a favor and use Cloudformation (or your favorite cloud's equivalent and just move on with your life)

<comment><USER4> I mean, this is harsh, but there's a running joke that the big feature terraform is missing is a -twice flag so that it'll re-run itself on failure, since that's what you end up having to do anyways.

Also, the terraform language, HCL? It's, I guess there's no better way to put this: not good.

Am I misunderstanding the complexity of what Terraform is trying to do? To me, it looks like a bunch of tiny API clients tied together with a topological sort --- in other words, it's just another species of "make". It feels like it carries a whole lot more complexity than that concept warrants, but _just enough simplicity_ to make it not a serious programming language. It's, to me, one of those frustrating uncanny valley systems.

I am prepared to be totally wrong about this.

<comment><USER5> Yeah, HCL's limitations have been an enormous thorn in my side for a long time. HCL2 (Terraform 0.12) is a big step forward, but even still I pine for a proper programming language, even if it has foot-guns.

I do think you're selling Terraform short, though. Sure, the core is the toposort-create-things. But it also stores the state of its created things and (crucially) has the ability to diff the actual state of resources against what it thinks they ought to be.

Being able to inspect existing resources and diff state is also what lets it import existing resources, so that they can be Terraform-managed going forward.

Terraform is also capable of determining if its planned changes can be performed in-place or if they require resources to be destroyed and re- created. That boils down to a boolean flag on a field, ultimately, but it's still something a dead-simple make clone probably wouldn't do well.

I've only really used Terraform seriously for AWS, so I'm not sure about the other providers, but the Terraform AWS Provider has an enormous amount of work behind it. Basically every resource API has schema validation written in the AWS provider, and depending on the resource there are often eventual- consistency issues handled by the provider. See for example [0].

In contrast, AWS CloudFormation: can't import existing resources; isn't always sure whether an update will require replacement or not; and, as of ~6 months ago, can detect configuration drift, _but not correct it_ (!). Of course, CloudFormation wins in other areas...

[0]: [https://github.com/terraform-providers/terraform-provider- aw...](https://github.com/terraform-providers/terraform-provider- aws/blob/master/aws/resource_aws_cloudfront_distribution.go)

<comment><USER6> Long-time user of Terraform here, never used CloudFormation. Where does CloudFormation beat Terraform?

<comment><USER3> Cloudformation will leave your infrastructure in a consistent state. Period. It will consistently drive things from point A to point B or rollback to point A if it cannot get to B. It will also correctly remember all the resources it created and allow you to properly identify them and/or delete them. These sound like tablestakes but Terraform cannot do this. Add the frustrations of HCL on top and it's a big no go for me.

<comment><USER5> I've had CloudFormation fail to roll back plenty of times, though never in a situation where it actually mattered.

I've never had Terraform "forget" resources or disallow me from deleting them (unless I requested that). Maybe those are bugs that've since been fixed?

It sounds like we've had very different experiences with these tools.

<comment><USER7> My experience with CloudFormation has been consistent with what you just said. CF will fail to delete resources and then lock them in that state, requiring AWS tickets and reps and all that. I have not had anything like that in TF.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> My biggest hope is that this means that some effort can be directed back to fixing bugs. I love what terraform can do, but I hate what I sometimes need to write to make it work.

Also, I'll go out on a limb and say that I dislike the flexibility of iteration allowed in HCL 2. I know that people overwhelmingly asked for it, but my opinion is that it demonstrates a fundamental misunderstanding of how the v. 11 and earlier system was designed, and just how powerful completely declarative code can be.

<comment><USER9> The biggest issue we have with Terraform (and other Hashicorp tools in general, really) is their different configuration formats, but mostly it is HCL limitations.

I haven't found a solution for it, but I have lots of resources that are almost identical, except for a few arguments, but right now it seems like my options are to either write my own Ruby script to output .hcl files, or live with two resources that are almost identical, and live with the mistakes that could entail by future modifications.

I haven't had the time to look into HCL2 yet, but maybe it is solved.

<comment><USER10> +1 for the question about a "standard" or recommended way to parse and generate .tf files from a script.

I have two use cases in mind: Use case 1: need to have a reproducible way to generate terraform folders for multiple almost-identical deployments (this can be solved via modules) Use case 2: need way to "promote" a deployment from staging to production (load a .tf file, change a few basic params then save again to a different folder --- doesn't really work with templates since I want to load an existing .tf file)

One thing that might work is to use the combination of two tools: \- [https://github.com/virtuald/pyhcl](https://github.com/virtuald/pyhcl) = reads .tf, can export .tf.json \- [https://github.com/kvz/json2hcl](https://github.com/kvz/json2hcl) = convert .tf.json to .tf but feels hacky...

Any other recommendations for .tf parsing and generation? (preferably in python or scriptable via python)

<comment><USER11> Your favorite tool that produces json should be able to work. I'd probably use jsonnet, which has a multi-file mode so that one template file can render into many json files.

</comment></comment></comment></comment><comment><USER12> We are very heavy users of terraform. We have thousands of lines of HCL and our own providers etc...

Terraform 0.x before 0.12 was heavily limited due to the syntax, you just worked around so many limitations. We are actively ignoring those limitations and we started working without our own templates using jinja that just generate vanilla terraform. No counts and no if/else needed.

Maybe with .12 we can move some of these back to plain terraform.

Upgrade so far is not smooth though, there are a lot of pains with the type system vs the plain old "I'll figure it out for you".

ALL of this being said, I really appreciate Hashicorp's work on this, we could not imagine our life without terraform.

</comment><comment><USER13> Terraform is an amazing piece of technology but the biggest thing holding it back is HCL. I guess the intention was for it to serve as a happy middle ground between a full blown programming language and a configuration language - enabling some abstractions, but yet rigid enough to stop developers getting too carried away. I think unfortunately that trying to have it both ways doesn't really work and ends up leaving those writing the code frustrated - it's almost as if it's teasing you - you can feel there's all this power under the hood and you are given things like modules which are nice, but you always feel like you're on a of short leash.

I switched from Terraform to Pulumi for a personal project recently and haven't looked back (no affiliation). Writing it with Typescript means you get excellent IDE support (using VSCode here) and access to the enormous JS ecosystem. I've also found myself creating a number of useful abstractions - that I would never have bothered to with HCL - like IAM helper functions, eg:

        const limitedReadAccessPolicy = createPolicy(
          "product-table-read-access",
          allow(
            ["dynamodb:Get*", "dynamodb:Query"],
            [table.arn, interpolate`${table.arn}/index/*`]
          )
        );

vs

        resource "aws_iam_policy" "product_read_access" {
          name        = "madu_${var.env_name}_product_read"

          policy = <<EOF
        {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Action": [
                "dynamodb:Get*",
                "dynamodb:Query"
              ],
              "Effect": "Allow",
              "Resource": [
                "${aws_dynamodb_table.products.arn}",
                "${aws_dynamodb_table.products.arn}/index/*"
              ]
            }
          ]
        }
        EOF
        }

</comment><comment><USER14> Terraform and Packer are the two most common tools I use with my DevOps consulting company. Most all of my clients previously were creating cloud resources manually within the U/I control panel. Moving to Terraform is a game changer in terms of transparency, auditability, and automation. With the release of Terraform Cloud[1] which provides centralized state storage, locking, history, and integration with GitHub the HashiCorp stack is a no- brainer.

[1] [https://app.terraform.io/signup?utm_source=banner&utm_campai...](https://app.terraform.io/signup?utm_source=banner&utm_campaign=intro_tf_cloud_remote)

</comment><comment><USER15> Congratulations to the team for a monumental release! The significance of the changes involved to ship 0.12 seems understated. This release paves the path to implement many highly requested features and fixes. Most noteworthy of which, in my opinion, is module counts.

</comment><comment><USER16> I've been very excited for this release. I'm a huge fan of Terraform—When I first started using it I quickly couldn't imagine working without it, despite its many rough edges. But it continues to improve (I can think of very few projects that have had such large and consistent improvement) and this release is another huge step forward. Props to Hashicorp for the great work.

</comment><comment><USER17> If you love terraform, please also look at Pulumi (I have no affiliation with them).

[https://pulumi.io/reference/vs/terraform.html](https://pulumi.io/reference/vs/terraform.html)

[https://github.com/pulumi/tf2pulumi](https://github.com/pulumi/tf2pulumi)

<comment><USER18> Honestly I like the idea of using declarative code for infra stuff because this way it becomes an inventory-like configuration language. There is a reason why YAML dominates today.

<comment><USER17> Terraform does not use YAML. And in the last updates they try to make their HCL more "programming language like". Pulumi is already there (they are using an actual programming language)

<comment><USER18> Of course Terraform does not use YAML. I mean that YAML or other approaches like HCL allow for a declarative style while maintaining some constructions like for-loops or conditionals.

Having your infrastructure in an inventory-like codebase makes it clearer to reason about. It can't go too crazy like most programs end up like

</comment></comment></comment></comment><comment><USER19> I work heavily with the Deployment Manager from GCP, so I am basically used to describe the infrastructure using python. What seriously bugged me about TF is how difficult it was to do simple stuff like having a nested loop within a resource. I know that 0.12 is supposed to help there and I am looking forward to the moment where TF will evolve into a proper programming language, supporting saner formats (already happening with json integration).

</comment><comment><USER20> As someone using Terraform from it's first release on I still think that Terraform has one fundamental flaw:

It always looks at things using provider specific resource, while IMHO it should just expose a bunch of predefined resource types (see rOCCI specs e.g.) and then allow you to attach a specific provider to it.

IMHO the biggest win as a user would be having not to have an implementation for every provider over and over. Do we really need to have a consul module for Azure, AWS, Tudeluuu and god knows who? No.

That being said, Terraform in the long run still is the most reliable tool in that space.

The whole situation about state management is... lacking. Experience says the one thing no client ever wants in the cloud but always on prem is state.

<comment><USER21> > The whole situation about state management is... lacking. Experience says > the one thing no client ever wants in the cloud but always on prem is state.

Hm, can you elaborate? S3 state seems perfectly serviceable, and I don't immediately see why I would want to operate on-prem resources just to maintain state.

<comment><USER20> S3 is Amazon. In some cases you want to exert control over your state without being dependent on external parties.

Currently Terraform Enterprise is the only approach to solving that and its a good one but... only if you're one of the big guns and even those sometimes think twice because the infrastructure state requires much more security than that offers.

<comment><USER22> There is nothing stopping you from backing up state in s3 and git. Just have CICD to sync it up.

State really shouldn't have anything secret in it in the first place, so 3rd party having access to it shouldn't matter.

</comment></comment></comment></comment><comment><USER11> Question that's been bugging me and I haven't quite wrapped my head around --

For light usage, I find managing Terraform's state to be a significant hurdle. You basically have no choice but to set up secure remote storage unless you want to check passwords into source control. In contrast `kubectl apply` is so easy to use since it's stateless. It just creates or updates any resources provided, and it even supports --prune if you want the set of configuration to be treated as comprehensive.

It seems like the main things that Terraform adds:

1\. The ability to work with providers that require you to store their generated IDs to reference later. With kubernetes, the kind and name of the resource is enough to identify it; it does get assigned a UID, but you don't have to include that in the configuration since keys that are excluded are left as-is.

2\. The ability to work with multiple different providers. I'm not sure how often you do have a single terraform project(is that the term?) with more than one provider, but I guess using the same set of tools, even if the configuration is provider-dependent, is nice.

Is that accurate? Does Terraform offer any other advantages?

If you were building a configuration mechanism for your system from scratch to allow your users to configure it as code, would you make .a Terraform provider over a command line tool that can apply [--prune] that same configuration?

<comment><USER23> Terraform shine when you combine multiple providers, kubectl manages Kube but Terraform helps you integrate K8s with the rest of your infrastructure (monitoring, Sentry,GitHub and GitLab, etc.)

> I find managing Terraform's state to be a significant hurdle Have a look at > [https://app.terraform.io/signup/account](https://app.terraform.io/signup/account), > it's the free version of Terraform Enterprise and it makes managing your > state very easy.

>If you were building a configuration mechanism for your system from scratch to allow your users to configure it as code, would you make .a Terraform provider over a command line tool that can apply [--prune] that same configuration?

I would make a Terraform provider, you get plans, modules, the possibility to integrate with other providers easily and creating a new Terraform provider is actually very easy!

</comment></comment><comment><USER24> I've been chasing infrastructure-as-code for a while, but I keep getting blocked by Terraform missing provider APIs (GCP Cloud Function Runtimes outside Nodejs, most recently), Kubernetes complexity, and generally being too lazy to sit down and bang out something in code that I can quickly iterate on with a console or quick CLI commands. I've had some wins with Serverless Framework, but outside that I've yet to see the payoff from the time I have put towards it. Am I defective?

<comment><USER25> Just not working at a large enough scale.

Infrastructure as code becomes progressively more important as you add resources until you're at the point where terraform does the job of a whole team of administrators who would be spending all day clicking through UIs.

</comment></comment><comment><USER26> The upgrade path for this has been an absolute nightmare, made worse by the fact that we sat on the `google` provider 1.16 (lots of GKE stuff like node taints was moved out to `google-beta` in `google` 2.0 and TF 0.12 requires `google` 2.5 at least). There isn't even a straightforward transformation for many things. I get why it's this way, but brace yourself.

I also made the mistake of `terraform plan`ning and updating my code as I went along. Just use `terraform validate`. Otherwise you're going to inadvertently promote the statefile before you're done dealing with all the issues (and you don't want that because it prevents you from aborting your upgrade and switching back to 0.11 till you're all ready). Not a real problem because the statefile is versioned but an annoyance nonetheless.

The type issues were mostly easy to deal with, except for where things that were assignments now being blocks. For instance, look at this:

          master_authorized_networks_config {
            cidr_blocks {
              cidr_block = "10.0.0.0/8"
              display_name = "Example /8"
            }
            cidr_blocks {
              cidr_block = "10.1.2.3/32"
              display_name = "Example /32"
            }
          }

That looked like:

        master_authorized_networks_config = {
            cidr_blocks = [
              {
                cidr_block   = "10.0.0.0/8"
                display_name = "Example /8"
              },
              {
                cidr_block   = "10.1.2.3/32"
                display_name = "Example /32"
              },
            ]
          }

before and `terraform 0.12upgrade` isn't about to help you navigate this. Especially if you previously assigned from a variable. In that case, it's going to make this monstrosity of a `for_each` over that thing. Jesus Christ.

Still, I'm thrilled for the new stuff with the more type-safety. Not going to complain. If this is the price, then I'll pay. I just wish they'd done more to help the upgrade, but it's an 0.x release so fine.

</comment><comment><USER27> Good stuff. It looks like they've addressed a few of the ergonomic issues in their language with this release. The old way of doing iteration and having to use string interpolations just to reference variables were annoying.

<comment><USER3> Hashicorp got it right with Vagrant and its Ruby-based DSL. At the end of the day you could always drop down to a proper programming language and express what you wanted if the DSL was lacking. Why they had to invent this HCL monstrosity is beyond me.

</comment></comment><comment><USER28> I'm a little unclear on terraform in practice.

As you supposed to download this, use it's language and syntax which is all it's own thing, to define you services and then export that to a YAML setup that AWS CloudFormation (for example) is expecting?

I assume there are reasons I wouldn't just define it myself in YAML directly?

<comment><USER29> As others have said, no exporting is involved. You write roughly-json-esque code which you then apply to a cloud provider.

The state of the infrastructure is stored, ideally, in the cloud. You apply your code during which terraform identifies which changes need to be made by comparing the current state with your local changes and executes those changes as you watch.

The end result is well-defined, testable, repeatable cloud infrastructure provisioning.

Infrastructure as code. Store it in git. Profit.

<comment><USER30> Where do you store your state files? The only project I've worked on that used Terraform stored state in a git repo, which seemed like a nightmare with multiple people doing deploys to the same environment. Others have suggested it would be better stored on a network accessible share.

<comment><USER31> I use a versioned S3 bucket to store state in my project, terraform also supports "locks" to avoid race conditions/parallel execution. I've set up buildkite to run `terraform plan` and then if the output looks I can approve the next step to run `terraform apply`.

Atlantis ([https://github.com/runatlantis/atlantis](https://github.com/runatlantis/atlantis)) is also a really cool project for managing teams working on terraform projects.

</comment></comment></comment></comment><comment><USER32> People often complain about HCL being very limiting, that they are sick of templating HCL, etc.

Has anyone tried the approach of writing some go code that imports terraform, rather than using the terraform CLI? This would give you the full power of golang to set up your resources.

</comment><comment><USER33> First of all, I don't want to dismiss the fact that terraform is a great tool and mostly on the right path.

But HCL is giving me Puppet DSL PTSD.

Folks at Hashicorp should just embed JS engine and let users write definitions using a real language (JS).

It's totally doable using library such-as Otto.

</comment><comment><USER34> For a second I confused this with TerraGen ([https://planetside.co.uk/](https://planetside.co.uk/)) and got all excited about reliving a nostalgic youth.

</comment><comment><USER35> From a language and semantics perspective, any comparisons to Nix?

</comment><comment><USER36> Language improvement is nowhere match to what Pululmi brings to the table without sacrificing any features.

</comment><comment><USER37> Terraform still isn't stable?

On the other hand, I'm usong React-Native, lol

</comment><comment><USER38> Finally

</comment><comment><USER39> > Terraform 0.12 is a major update

Looks like a minor update to me...

<comment><USER40> Before stable version x.y.z, if x is 0, then y means major

<comment><USER41> I am astounded that after all this time it is still 0.y.z

I mean, it has been around for like 5+ years...

I am even more astounded that people are happy to use a product that by its own definition is not stable.

Same happen in ruby a lot. You find a Gem that claims to follow semantic versioning and it is still in 0.y.z after years of being used in production which flies in the face of [https://semver.org/#how-do-i-know-when-to- release-100](https://semver.org/#how-do-i-know-when-to-release-100)

<comment><USER42> Where does Terraform claim to follow semver?

<comment><USER40> Where doesn't it claim it? Using a versioning scheme like x.y.z _by default_ means semver

<comment><USER22> No it doesn't. Why would you think it does?

</comment></comment></comment></comment></comment></comment><comment><USER43> I moved away from Terraform a long time ago. Ansible was way more powerful, handled errors and issues with state changes. Terraform was super picky about how you had to operate, slow and HCL was a terrible markup language. I wasn't really a huge fan of Ansible either though and more recently have been doing things in regular shell/Bash scripts. Now with Kubernetes and service brokers, there is no need for Terraform.

<comment><USER15> Ansible can very easily, and often does, end up in situations where two runs of the same playbook both have drastically different results. roles/playbooks slowly become Bash scripts written in a YAML layer parsed as a Jinja2 template.. and the project turns into a mess of many layers of indirection.

it attempts to and encourages declarative configuration, but is very hard to keep that way. it is difficult and requires determination to make Terraform do something in a non-declarative fashion.

the end result is that when I look at a Terraform configuration I can very easily tell what is going on, because the end result is exactly what I read. where with Ansible, it very much depends on understanding the current state of the server you are about to run this playbook on, and you just have to cross your fingers and hope for the best.

<comment><USER44> Maybe you never worked in a company with good ansible practices.

<comment><USER15> following best practices with C will get you code without memory leaks or overflow errors, yet here we are in 2019 still routinely dealing with those in mission critical software written by people who understand what they are doing.

Terraform is a tool designed to overcome the problems that "best practices" will supposedly prevent you from introducing in your Ansible playbook.

don't get me wrong. Ansible is a wonderful tool for certain applications (configuration management). I would just never use it to spin up infrastructure again.</comment></comment></comment></comment>


Free Hours to a Startup - <AUTHOR>

I work with quite a lot of start-ups in my current main job as a lawyer. As a result, I often get asked for help from friends and sometimes volunteer it. Recently, I was asked if I would be willing to offer a few hours of help per week (the company is post seed, pre-A)....
I really like the idea and the people and am keen to learn more about their activities, but I also work long hours and would basically be saving them quite a bit in legal or other advisory fees....
I have some thoughts and am happy to share, but first I'm curious to see what people think? Pros and cons of giving this help? Should I be expecting/demanding options or other compensation? Any experiences of this kind of thing ending well/badly? <comment><USER2> What do you want to achieve?

(1) Learn more about the startup world (2) Help out some startups (3) Business development for new clients when they raise $ and can afford you.

The answer will depend on which one you're aiming for. My guess is that -- depending on how early the startups you're working with would be -- technical founders would end up looking to you as advisor on topics like negotiation, business development, and fundraising, rather than strictly legal advice. Generally after you help a startup 2-3 times they should give you some equity as an advisor.

<comment><AUTHOR> Fair questions- I should have been more specific (and that will be part of my own thoughts once I have a few more replies). To be honest, I want to achieve all of those. 3) may not be that likely as they already have very well established legal counsel, though it is obviously still potentially there as an option and was how I started giving them a bit of help...

Also true that they weren't necessarily looking for strictly legal help but more analytical / advisory as you suggest.... so on that basis, what do you think?

<comment><USER3> > they already have very well established legal counsel

If that's the case, why are they asking you for help? Either their existing counsel is bad or they don't want to pay.

Maybe if they are looking for advice around some of the things that aren't strictly legal (e.g. negotiation), that makes sense. I agree with another comment that after about 2-3 times, it's probably worth sitting down and offering your services as a true advisor and the rewards/responsibilities that come with that.

<comment><AUTHOR> Yeah - I think it is a combination of money and not strictly legal.... but what does 2/3 times mean? Reviewing an investor deck might take me 20/30 mins... it's not really a big deal. Advising on a contract is obviously a much bigger deal...

</comment></comment></comment></comment><comment><USER4> A startup is a business, not a charity. Don't kid yourself that freebies are _pro bono_ in any sense whatsoever. To put it another way, giving these people free legal advice makes as much sense as them just giving you stock based on friendly feeling.

Charge your regular rate or don't do it. You don't need clients who don't value your time enough to write you a check. And you damn sure don't want them to tell all their friends or that big future project that also doesn't pay. Work with professionals.

Good luck.

<comment><AUTHOR> Thanks... I get that, but they aren't my "clients" in the sense of a client of my firm.... it is less formal than that (at the moment).... hence the question and it's about balancing a "way in" with "learning" but also being compensated if appropriate.

<comment><USER4> It's less formal _only_ because you're acting as if it's not business. But I suspect you're the only one, the erstwhile clients are _and_ they are demonstrating a perfect willingness to not pay you for your time.

It's a tell. Most people who will screw you live with themselves under the rationalization that they gave fair warning. You're hanging around past the initial conversation where a little free friendly advice is socially appropriate among acquaintances, and now past the point where it's clear that a normal business transaction is in the works. You're the one _buying_ and the seller has been clear: *caveat emptor".

You're not part of this deal. You have no leverage to force your way in. If the company grows, then paying work for you may be created organically. It's only worth playing long.

</comment></comment></comment><comment><USER5> One possible solution would be if you genuinely enjoy offering advice to startups, you could always look at it as a hobby. Honestly, I'm not sure someone with a conscience would be okay asking for help without at least offering something/anything (money, golf, beer, w/e). Everyone needs help at one point or another, and you may want to work or volunteer with people who value your contributions.

</comment><comment><USER6> Startups typically compensate in equity and/or some deferred payment contingent on the next round when they ask attorney's for services that can't be paid for in cash immediately.

<comment><AUTHOR> I should clarify: I am not being asked to offer help as the company lawyer per se (they have legal counsel and I am generally familiar with the deferred payment model)... this is more of a "asking a friend for [free?] advice" situation</comment></comment>


Ask HN: What's the best host for a small site? - <AUTHOR>

Ideally inexpensive, and with PHP/MySQL support in order to run something like Laravel. I was going to use DigitalOcean, but would like to avoid the server hassle.<p>Thanks! <comment><USER2> I prefer [https://www.openshift.com/](https://www.openshift.com/) . It's free for small apps.

</comment><comment><USER3> I've been using [https://www.nearlyfreespeech.net/](https://www.nearlyfreespeech.net/) for a few years now to host my RSS aggregator. NearlyFreeSpeech is a pay what you use hosting service and it is very cheap.

</comment><comment><USER4> I use [http://angryhosting.com](http://angryhosting.com) and it's great. $12/year for the most basic plan. Don't expect much in the way of support, though

</comment><comment><USER5> I've been happy with A Small Orange. Their $35/year plan will do the trick.

[http://asmallorange.com/hosting/](http://asmallorange.com/hosting/)

</comment><comment><USER6> I use [http://www.tigertech.net/](http://www.tigertech.net/) and I am extremely pleased

</comment><comment><USER7> I use Heroku for my rails app. If the site is really small, then heroku is 100% free.

</comment><comment><USER8> appfog also has a free tier?</comment>


Ask HN: Long-time Arch Linux user, just bought a MBA, what do I need to know? - <AUTHOR>

<comment><USER2> Do you want to use Arch on your Mac? Arch Wiki and the forums will help with that.</comment>


Barry Martin's Hopalong Orbits Visualizer - <AUTHOR> https://iacopoapps.appspot.com/hopalongwebgl/ <comment><USER2> This is awesome. Reminds me of the ayahuasca trip scene from the movie Renegade. This could easily be made into a game where you have to avoid hitting any of the particles, and you get more points by going through smaller rather than larger holes.

</comment><comment><USER3> Beautiful! And such a simple formula (click "About").</comment>


Principles of designing Go APIs with channels - <AUTHOR> https://inconshreveable.com/07-08-2014/principles-of-designing-go-apis-with-channels/ <comment><USER2> This one too: [https://github.com/astaxie/gotraining-1/blob/master/08-concu...](https://github.com/astaxie/gotraining-1/blob/master/08-concurrency_channels/03-channels/documentation/channels.md)</comment>


How recursion got into programming: a comedy of errors - <AUTHOR> http://vanemden.wordpress.com/2014/06/18/how-recursion-got-into-programming-a-comedy-of-errors-3/ <comment><USER2> The article doesn't mention _why_ people didn't want recursion to be a requirement. It was probably because the idea of using a call stack was still controversial.

For instance, on a PDP-8 (released some years after ALGOL) the calling convention was that the return address was written to the word of memory before the called function. This was simple, but pretty much precludes recursive calls.

These days we take for granted that the CPU will provide some sort of stack pointer that gets automatically managed by a CALL/RET instruction pair. Before that was provided in hardware, the compiler would have to do that itself. So if you decided to support recursion, you'd end up requiring a stack and adding a small cost to every function call.

Once you decide to have a stack, allowing recursion is a freebee so of course you'd include it.

<comment><USER3> > The article doesn't mention _why_ people didn't want recursion to be a > requirement.

It does, actually:

> And this is what they wanted to remove because they wanted static allocation > of procedure activation records.

A stack frame is a _dynamically_ allocated procedure activation record, but we no longer call them that because it's seen as absurd that they would be statically allocated.

<comment><USER4> I wouldn't say it's _absurd_ , as it's legitimately very useful (though onerous) to be able to statically determine the amount of memory that will be used by a program. To this end, it is indeed true that tail-call elimination can remove the need for dynamically-allocated stack frames in the face of recursion. However, AFAIK, it is undecidable (given a Turing-complete language) to determine if a program contains _only_ TCE-compatible recursion. In the face of that, you would have to forbid recursion entirely via a mechanism like the "declaration must precede use" rule mentioned in the article.

<comment><USER5> Whether a call is a tail-call is trivially decidable; it's an entirely syntactic condition (a call to f is a tail-call just in case it's of the form "return f(...);").

It's true that it's not possible to make a Turing-complete language for which it's possible to statically determine the amount of memory arbitrary programs on arbitrary inputs will use. But typically a language has other means of supporting dynamic memory allocation than simply via frame allocation for functions; e.g., via built-in operations to manipulate lists of arbitrary length.

So, if you wanted to only allow recursion via tail-calls, you easily could, and if you wanted to furthermore go ahead and prevent all dynamic memory allocation, you could as well, but you would necessarily be giving up Turing- completeness.

<comment><USER6> I don't see the relationship between Turing-completness and dynamic memory allocation.

Even in a classic Turing machine I interpret the tape as a single pre- allocated array (of infinite size).

When talking about Turing-complete programming languages, a relaxed definition with finite-size memory is assumed, and to me it seems that it's just hair splitting whether program hits that limit via malloc() call or by advancing a pointer in an internal fixed-size array. Dynamic memory allocation is just a name for a bunch of bookkeeping done on a fixed-size memory.

In practice asm.js programs are not allowed to dynamically allocate any memory from the browser: a fixed-size array is created before the asm.js program starts. From the point of the VM programs are just shuffling bytes within a fixed-size array, and yet, we can run "Turing-complete" programs in asm.js.

<comment><USER5> A finite memory machine is a finite state machine. These are not Turing complete. The notion of Turing completeness becomes uninteresting if we can't even draw this distinction.

"dynamic memory allocation" may not have been the right term to use to denote moving beyond finite state machines, for an audience which wants to consider a Turing machine as having statically allocated infinite memory. But it makes sense if you think of a Turing machine's memory as only storing enough data for the portion of the tape which has already been accessed, and allocating new memory as new tape regions are needed.

It's true that the actual machine sitting on your desk only has a fixed finite memory. In that sense, without a peripheral unbounded store, it's not properly Turing complete.

It's also true that we often find it convenient to analyze it as Turing complete anyway, but this abstraction basically goes hand-in-hand with abstracting away its memory limitations. I don't see any point in pretending you can be Turing complete using only programs with a statically given memory bound (which amounts to a logarithmic bound on the number of states in a corresponding finite state machine); if we're going to pretend, let's pretend the memory is effectively infinite as well.

<comment><USER7> The problem with analyzing programs in the context of a fixed memory limit is that you would have to revisit all of the proofs whenever the fixed limit was increased. If you can prove something true for unlimited memory, it's also true for any limited amount of memory.

>>we often find it convenient to analyze it as Turing complete anyway

It's convenient, because the proofs will still be true even if memory sizes grow by 500x. Turing machines clearly don't have a real, material existence, similarly to real numbers (assuming that all actual numbers are finite). Real numbers can be considered as modeling integers that are arbitrarily large.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This has some solid political advice courtesy of Peter Naur: If you want to get a committee to do what you want, show up with most of the work already done. That work became the starting point for all the future negotiations. And his influence on Algol-60 spec was a strong contributor to him receiving a Turing award years later.

</comment><comment><USER9> There is a book called The Little Schemer (was The Little Lisper) - a book all about recursion. This is a quote from a review:

 _Little Schemer is without a doubt one of the best books I have ever read on the subject of recursion, and what is interesting because they never really go into a formal definition of what recursion is, as most texts on computer science try to. Instead they show the reader time and time again what recursion is, while providing a great series of rules (commandments) on how to get the most out of recursion, particually in a tail-recursive language like Scheme._ [http://www.amazon.com/The-Little-Schemer-4th- Edition/product...](http://www.amazon.com/The-Little-Schemer-4th- Edition/product- reviews/0262560992/ref=cm_cr_dp_synop?ie=UTF8&showViewpoints=0&sortBy=bySubmissionDateDescending#RCZ626B7P2J1C)

You can read more about The Little Lisper here: [http://thelittlelisper.blogspot.com.au/2010/06/little- lisper...](http://thelittlelisper.blogspot.com.au/2010/06/little-lisper- chapter-1-toys.html)

Or you can read about working through it in Clojure here: [http://juliangamble.com/blog/2012/07/20/the-little- schemer-i...](http://juliangamble.com/blog/2012/07/20/the-little-schemer-in- clojure-chapter-1/)

<comment><USER10> The Little Schemer is fantastic. I recently picked up The Seasoned Schemer as well, but haven't gotten a chance to really dive into yet. I'm looking forward to seeing how the authors tackle more advanced topics using their out of the ordinary teaching style.

Now, go cons a cake onto your mouth!

<comment><USER11> They've also got a 3rd book in the series, _The Reasoned Schemer_ [1]. I didn't finish working through it (life and work and other things), but it's pretty good as well.

[1] [http://mitpress.mit.edu/books/reasoned- schemer](http://mitpress.mit.edu/books/reasoned-schemer)

<comment><USER12> Be warned that, despite the name, the Reasoned Schemer is only tangentially about scheme; it focuses on miniKanren, a somewhere-in-the-Prolog-ballpark logic programming language created by one of Friedman's students, that is implemented as an extension to the Scheme language proper (among other languages, most notably as the clojure core.logic library).

Also Friedman and Byrd did show up to a few clojure talks and seemed, from the online videos, to be highly entertaining - I remember their using miniKanren to automatically generate scheme programs that evaluated to 6 being particularly fun.

</comment></comment></comment></comment><comment> mark-r It may seem trivial now, but when this was being considered stacks were not a built-in CPU feature. In fact I wonder what was the first architecture that included one?

The machine I learned assembler on would rewrite the instruction at the start of a function with a jump instruction to return to the caller. You returned from the function by jumping back to its beginning. Recursion wasn't an option!

<comment><USER13> To get even better idea, the memory used at that time didn't even have to have 8-bit bytes:

[http://www.computermuseum.li/Testpage/IBM-1401.htm](http://www.computermuseum.li/Testpage/IBM-1401.htm)

"It came with 4,096 characters of memory [6-bit (plus 1 parity bit] CORE memory, constructed from little donut shaped metal rings strung on a wire mesh."

The core memory is explained in the same book which deanmen linked (thanks deanmen!)

[http://www.jklp.org/profession/books/mix/c01.html](http://www.jklp.org/profession/books/mix/c01.html)

</comment></comment><comment><USER14> Recursion isn't allowed for safety critical code in automotive or avionics applications

[http://spinroot.com/p10/rule1.html](http://spinroot.com/p10/rule1.html)

<comment><USER15> The rational is vary reasonable. Basicly, all recursion can be replaced by a loop that does not risk blowing the stack or using extra memory. However, tail call optimization is basically the compiler doing that conversion for you which also removes the risks.

<comment><USER16> Replacing recursion with a loop can easily use extra memory. The usual approach is to implement a stack using a local variable: each iteration pops the head and processes it; rather than recursing, we push a new item and let the next iteration process it for us.

If the algorithm is tail-recursive, this will use constant stack space and memory, just like tail-call optimisation. If the algorithm's not tail- recursive, it will use constant stack space but large (potentially exponential) amounts of memory.

There's no way around this. The only solution is to come up with a different algorithm (eg. using an accumulator).

<comment><USER17> You're usually better off with manual recursion, if you're concerned about running out of space, for the simple reason that it's far easier in practice to back out of an out-of-memory situation than from a stack overflow.

</comment></comment></comment></comment><comment><USER18> Peter Naur is actually The Unterminator: a robot from the future, in which machines running non-recursive programming languages ruled the world. SkyNet had hit the wall of complexity because it consisted of so much legacy code written in non-recursive FORTRAN. Its only means of recursion was to build a robot and send it back into the past to change the course of history, and introduce recursion into Algol, against the wishes of the wiser committee members who suspiciously and correctly viewed recursion as a means by which computers could take over the world.

</comment><comment><USER19> To me recursive thinking was more important than recursive execution of functions. For instance, I find the recursive solving of the powerset function so appealing. ... (here in scheme).

        ;;; power set = power {set-X} as sub (+.) {X U sub}
        (define (power set)
          (if (null? set)
              '(())
            (let ((sub (power (cdr set)))
      	      (augment (lambda (subset) (cons (car set) subset))))
              (append (map augment sub) sub))))

Seeking self-similarity often lead to tiny solutions.

<comment><USER20> _Just fifty years ago, John McCarthy circulated a notice that he would be giving an informal talk that he thought would be of interest. I drove up to MIT from New Jersey to attend this seminar of typical length in a typical classroom. But the seminar was anything but typical. It was a revelation. In one session at the blackboard, John introduced Lisp—all you could do with car, cdr, cons, cond, lambda, and recursion.

Recursion had no place in mainstream programming at the time, nor did lambda calculus. Only two years before, I had sat in a coffee-room discussion of what it would mean for a subroutine to call itself. Questions raised but unanswered were whether recursive instances deserved to be deemed the "same" subroutine, and, if you could do it, what good would it be? It turned out you could do it: I programmed it for the IBM 704. Given the challenge, the now standard stack solution arose inexorably. But the question of what it was good for remained.

In the course of the lecture John introduced the usual basic list functions like copy, append and reverse (quadratic and linear), as well as tree manipulation. He went on to higher-level functions, demonstrating maplis and lambda. By the end of the hour he had put together a powerful little toolkit of functions which he used in his finale: symbolic differentiation of univariate expressions.

There it was—functional programming ex nihilo. McCarthy acknowledged IPL V and recursive function theory, but the elegant and practical face he put upon these antecedents was a work of genius. Nobody would ever again wonder what good it was to allow functions to call themselves. And it was all so clear one could go home and build it oneself without any instruction book._ \- Doug McIlroy

<comment><USER21> I would LOVE to see that lecture...

<comment><USER19> Same here, but a quick google search always bring up McIlroy comment. If you find it, submit it on HN :)

ps: there's a post on Recursion in early languages [https://news.ycombinator.com/item?id=8073361](https://news.ycombinator.com/item?id=8073361) that mentions McCarthy indirect influence on the ALGOL comitee, but nothing else.

</comment></comment></comment></comment><comment><USER22>
      > Ritchie relaxed the definition-before-use rule by allowing
      > redundant declarations of procedure headings. At the
      > expense of a redundant advance declaration the programmer
      > can define mutually recursive procedures in C.

Point of order: C didn't have a declaration-before-use rule until C99. C had 'implicit int'; no redundant declarations necessary.

<comment><USER23> I thought ANSI C had that roughly around 1990? I remember having to forward declare functions when I took C at University in around 1991 or so.

</comment></comment><comment><USER24> This is a wonderful piece of computer science history, and is of interest less for its nominal topic (recursion) than for the insight it gives into an early slice of languages research. Well worth a full read.

</comment><comment><USER25> The most interesting part of this story is considering what it would've been like if they decided to forbid recursion. Protecting the call stack from it would've been incredible overhead back then - either that or they would've had to enforce strict dependency ordered compilation and even then..

I imagine John McCarthy and the others who wanted recursion just sitting back and smiling, recognizing that that there was no need to press - it was just a matter of time.

<comment><USER26> The boring way would anticipate C with "the behavior in that case is undefined"; it sounds like the less-formal attempt was like that. Cynically I'd expect such an outcome from a committee design, so Algol really was something special.

</comment></comment><comment><USER27> How often is recursion used in everyday, imperative-style code? Do stack limits make it impractical to use?

<comment><USER28> Stack limits are pretty large. It's a natural way to express many problems such as graphs (and their subsets trees).

When people talk of "Tail Call Optimization" (TCO) they are talking about a way to recurse without leaving things on the stack (tail-call meaning that the recuse call is the last thing in the function so the state of the function doesn't need pushed on the stack, it can be discarded.

<comment><USER27> Oh, I definitely see the elegance of expression programs or concepts recursively.

Is TCO used in C++? I've only ever seen it mentioned in reference to Scheme and Haskell. It's a compiler optimization, so it would be transparent to the programmer, right?

<comment><USER29> TCO is available in plenty of other languages as well. Scala, Clojure, Erlang, and Elixir support it out of the box. Ruby has a VM setting for it, and there was a proposal to add it to JavaScript. I'm sure there are plenty of others.

<comment><USER30> Per ch4s3's comment on Clojure, Scala also does not have TCO, at least, last I checked. The JVM doesn't allow it. It has a specialized handling of functions that call themselves, which it can optimize, but A that calls B that calls A that etc is not (nor, in the more general case where any function that ends with a function is removed from the stack).

<comment><USER31> Yes it does.

That is an implementation detail. It doesn't matter if it is does at compiler or whatever runtime is targeted.

This is called _lowering_ in compiler design speak.

<comment><USER30> Umm...yes, it does matter.

Closures? Can't be optimized. Polymorphic method? Can't be optimized (even if every implementation is tail recursive).

This is more than an implementation detail, it actively influences the way you write your code.

And Scala -doesn't- optimize A calls B calls A etc cases. It requires the developer to explicitly make use of scala.util.control.TailCalls. See [http://www.scala- lang.org/api/2.11.2/index.html#scala.util.c...](http://www.scala- lang.org/api/2.11.2/index.html#scala.util.control.TailCalls$) and associated white paper.

What Scala gives you is that if A calls A (calls A calls A), and is tail recursive, and A can not be overridden, it will optimize it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> So I guess, if we look past the topic of recursion itself - that the moral of the story is that design by committee works if kept in check by a benevolent dictator? Perhaps it works both ways: that a benevolent dictator can be properly grounded by a committee.

</comment><comment><USER33> " _For example, in [6] the lambda calculus is defined in 86 lines distributed over ten definitions. It seems clear in this compact definition that lambda calculus does not allow recursive function definitions. Yet already by 1935 at least two versions had been discovered of the Y combinator, an expression of the lambda calculus. And this combinator makes recursive function definitions possible in lambda calculus._ "

My understanding was that without recursion the lambda calculus is not Turing- complete. Is that correct?

It should also be noted that recursion is a close relative of induction, an indispensable tool that is not without its own problematic history.

<comment><USER34> That is correct, but recursion in the lambda calculus is emergent from the rules, not a rule in itself.

</comment></comment><comment><USER35> "Oh whoops, I accidentally called this function inside of its self! Silly syntax error....but it looks like I traversed a binary tree..."

</comment><comment><USER36> I didn't know that F.L. Bauer was against recursion :-) In 1996 I participated in a summer school where he attended the talks we gave (mine was about Petri nets). Funny to see him mentioned here as a figure of history.

</comment><comment><USER37> re.curse _v._ To curse again.

<comment><USER37> Really? Downvoted because you lack a sense of humor?

<comment><USER38> People are downvoting because this is not reddit. Off topic discussion is far less welcome here (though tolerated if suitably interesting).

<comment><USER37> Thank you.</comment></comment></comment></comment>


The Rejection Book: Good luck, bad luck, who knows? - <AUTHOR> http://josephwalla.com/the-rejection-book-good-luck-bad-luck-who-knows <comment><USER2> If you liked reading this post, I highly recommend Vonnegut's Slaughterhouse Five. One of my favorite quotes, "So it goes," is repeated often throughout the book, and though it usually refers to tragic circumstances, it too hints that life will throw major wrenches in our plans that we shouldn't try to completely ascribe meaning to.

<comment><USER3> Upvote.

That's one of my favorite quotes and I almost mentioned it in the post. "So it goes" is mentioned 106 times in Slaughterhouse Five. After reading the book, I found myself saying it as often as 'good luck, bad luck, who knows?"

</comment></comment><comment><USER4> I really enjoyed reading this. It neatly and succinctly encapsulates life's little uncertainties.

As someone who's seen his share of rejections (as well as the inverse) lately, I can certainly identify.

<comment><USER5> Agree! I enjoyed it very much! This "good luck, bad luck, who knows?" already became a "instant classic" for my life philosofy... I am really glad I got caught by the title and encouraged to read by your sincere compliment. Thanks! (sometimes I feel that HN doesn't know how to just give sincere compliments, everybody want to look smart and neat and add some complement or criticism on the OP, instead of just saying it is just fine as it is written).

</comment></comment><comment><USER6> Great article. Rudyard Kipling warned us of the same when he wrote:

"If you can meet with Triumph and Disaster / And treat those two impostors just the same"

This is the main theme of the book "Hannibal and Me: What History's Greatest Military Strategist Can Teach Us About Success and Failure", written by Andreas Kluth of The Economist. If you enjoyed the OP's post, and love history (or just great storytelling), get the book. Promise you won't regret it.

 _Some wisdom from the book_ (from notes I took):

Those who experience tremendous success early in life are likely to have hit a peak. The wandering types who experience success later in life are more likely to sustain success for longer. [The book has an entire chapter analyzing "Towering Peaks" vs. "Wanderers"…a must-read for those who feel behind.]

Always keep the end goal in mind. Don't confuse tactics with strategy. Succeeding in the wrong things will lead to failure.

Dealing with disasters: A "Fabian Response" is one that accepts reality for what it is and then goes with the flow of things that cannot be changed until there is something that can be changed. In other words, accepting reality and then not doing anything - until there are viable alternatives. The key wisdom here is that sometimes the best plan of action is inaction. But don't confuse this with giving up. In this case, inaction is tactical, a part of a plan to succeed.

Keep as clear and calm a mind as possible in pursuit of success, and in response to failure. Always maintain EQUANIMITY. In fact, don't worry about success at all....just focus on doing your best.

Success can be imprisoning in many ways, and needs to be feared. Here are some reasons why: 1) Success is often followed by less discipline and focus. 2) Distractions, such as too many opportunities, or just plain overload of low- value work. Often the source of the success in the first place is forgotten or demoted because of these distractions. 3) Hubris that makes one think he is invincible. 4) Affects social relationships due to paranoia that others aren't as trustworthy anymore, are acting different, etc. Successful people waste time & energy dwelling on these. 5) The confidence and relaxation that accompanies great thinking and creativity (and thus responsible for the success) are replaced with anxiety and self-doubt. This kills the freedom of the mind. 6) Stubbornness and inflexibility that comes with being an authority/expert, which also kills the freedom of the mind.

[http://www.amazon.com/Hannibal-Me-Historys-Greatest- Strategi...](http://www.amazon.com/Hannibal-Me-Historys-Greatest- Strategist/dp/1594488126)

<comment><USER7> Ordered _Hannibal and Me_. Thanks for the recommendation.

</comment></comment><comment><USER8> I really like this approach to life. Opportunity really comes when you least expect it. I've been canned from jobs and thought my world was over only to find an even better job. So now I try to see everything as an opportunity. It sounds cliche but it really helps.

</comment><comment><USER9> I like that quote - Good luck, bad luck, who knows?

<comment><USER10> The _Lieh Tzu_ is one of the classic Taoist books for a reason.

<comment><USER11> <http://www.noogenesis.com/pineapple/Taoist_Farmer.html>

Yes, nice reference, thanks. I read an English translation of the Tao years ago but never explored the folk story aspect.

</comment></comment></comment><comment><USER12> Thank you so much for this post, this gives me a little bit of hope and urge me to keep trucking.

I too was a man full of rejection:

1\. I was kicked as a co-founder of a successful startup. 2\. Upon finding a full-time job, a year later I was fired and have a lawyer to write demand letters for me which I never comply. 3\. Found another job to work remotely that require me to have a Macbook Pro, but being financially short I converted my only desktop to a hackintosh. Then months later they send somebody at my house and upon discovery that I don't have a Macbook Pro I was fired. 4\. Found another job, months later I was being shouted to leave the office and was fired. 5\. Found another job, I was really happy I was into mobile app development, and 2 weeks away from release and shipping of the app, I was fired and the app didn't get shipped.

Right now I'm hoping to get into developing my own product, only if I have the strength to move on, and this post gives me a little bit of hope, I say 'Good luck, bad luck, who knows?'

</comment><comment><USER13> Thoughtful, well-written and super inspiring. Nice post Joseph.

</comment><comment><USER14> I personally have no problem with rejection per se. However, I find it particularly annoying when companies don't send any kind of response back.

<comment><USER15> That's why it is brilliant idea to call them back and ask why! (Which is what the article author did in case of Foreign Office.)

<comment><USER14> How do you call them back? It's not like a good company will leave their phone number of the HR department so that you can call them as you please.

</comment></comment></comment><comment><USER16> I've been listening to the 4HR WorkWeek by Tim Ferriss (because 580 is so much better with an audiobook.) In it he describes getting comfortable with rejection. One of his exercises is to ask 3 attractive people for their number. Hmrph...might try that. :)

</comment><comment><USER17> Can anyone link to AirBnB's 999 days without traction that he mentioned?

<comment><USER18> <http://www.justin.tv/startupschool/b/272180383>

</comment></comment><comment><USER7> Vipassana meditators here will recognize: Anichchha ...

</comment><comment><USER19> <http://www.richardwiseman.com/research/psychologyluck.html>

</comment><comment><USER20> Check out Jia Jiang's 100 days of Rejection Therapy here: <http://entresting.com> \- he video records his rejections and they're fun to watch.

The official Rejection Therapy website is here: <http://rejectiontherapy.com/rules></comment>


Building an Arduino-powered, mobile-controlled irrigation system - <AUTHOR> http://www.stavros.io/posts/arduino-powered-irrigation-system/

<comment><USER2> It seems to me that the following is liable to misclassify some pressure drop events as normal shutoffs: > } else if ((statesChanged[2] == 1 && pinStates[2] == OFF) && > (statesChanged[3] == 1 && pinStates[3] == OFF)) {

We look at the relay outputs twice a second and expect to see two of them switch within the same half-second in some cases. Even if they were actually depowered at the same instant in time, you'd often get a tens of millis window when one of them is already off, but the other isn't; then (irrespective of which was off first) you'd get a "Pump stopped" notification instead of a "Pressure dropped" notification. Am I missing something obvious or is that case just rare enough that handling it isn't worth the complexity?

</comment><comment><USER3> I really like how this kind of technology is finally very cheap and even usable for non-experts.

However, why is it that this kind of electronics is only ever used to irrigate plants, open/close doors or windows and maybe control lights in a room.

The arduino platform seems very popular, yet where are the really amazing projects? It really seems like it's just some kind of Lego for grownups. I bought some of this stuff too and it is cool to play with electronics, but it seems to me this stuff is merely good for learning electronics and just a fun hobby.

<comment><USER4> I've done some fun stuff with Arduinos, but sadly when I try to post it here it never makes it to the front page. For example check out this smart cocktail shaker project that uses Arduino & Android with a kitchen scale: [http://learn.adafruit.com/smart-cocktail- shaker](http://learn.adafruit.com/smart-cocktail-shaker)

<comment><USER5> Cool project, this combined with a database where you told it what ingredients you had available and it told you all the drink recipes that are you can possibly make would be killer for learning new drinks at home. Furthermore, also suggesting ingredients you should add to your bar next to maximize the number of new recipes available to you would be amazing. Add the ability to keep track of what you tried and your ability to add star ratings per drink would be an amazing product. I can think of few better ways to explore the world of cocktails and keep track of what you really enjoy in a drink.

</comment></comment></comment><comment><USER6> Indian farmers were doing something similar back in 2009: [http://www.pcworld.com/article/168895/article.html](http://www.pcworld.com/article/168895/article.html)

</comment><comment><USER7> How secure is it to connect an Arduino to the internet? Does it support any secure protocols?

<comment><USER4> Not directly--with only 32kb of program space in the Arduino Uno you can just barely get a wifi stack in (see the CC3000 chip), but there's no room left for SSL or anything secure.

A better option is something like the Arduino Yun which has two processors, a small Atmel microcontroller and an Atheros system on a chip running OpenWRT linux. The linux processor can act as a bridge to let the microcontroller communicate with the internet pretty easily.

<comment><USER8> At that point, just use a RaspberryPi unless you're specifically doing it for the challenge of it. Arduino is fun though.

<comment><USER9> Not really. There are some pretty considerable disadvantages to using the Raspberry Pi for the sorts of things the Arduino excels at. There are more, more resilient GPIO ports, there are more ADC ports, there are more PWM ports, the Yun can enumerate itself as a USB slave device, which can allow for all sorts of other cool uses, etc. Each device has pros and cons that you have to take into consideration.

<comment><USER10> What are some uses of a USB slave device?

<comment><USER9> It can be, to your computer, like any other USB device. So you can set it up to be a USB keyboard, USB joystick, USB storage device, etc. So, when you plug it in, you can have it set up that configuring the device, or getting logs, works like any other file operation, similar to how the wifly looks to a camera like just another sd card. Or have it enumerate as a usb input device, and use it to control and be controlled by a pdp 11 front panel ( [http://retrocmp.com/projects/pdp-1170-panel/25-pdp-1170-cons...](http://retrocmp.com/projects/pdp-1170-panel/25-pdp-1170-console- panel) ). In short, it lets you tie whatever real-world interface device you've made to whatever pre-existing computing metaphor makes the most sense...or creating your own driver to let the sky be the limit.

<comment><USER10> Cool, thanks for the explanation.</comment></comment></comment></comment></comment></comment></comment>


Ted Dziuba:  I'm done with trolling the tech community. - <AUTHOR> http://teddziuba.com/post/24585610978/starting-over

<comment><USER2> Personally, I thought his old articles (which he seems to have completely deleted from his website) contained a good combination of quality insight and humor. The humor was basically rude invective, which puts some people off, but sometimes that's what you need to get people talking. I'm sure his future technical articles will be just as insightful as they were in the past, but will they be as widely read and appreciated?

<comment><AUTHOR> You can still grab a lot from his GitHub repo which hosted the blog - <https://github.com/teddziuba/teddziuba.github.com></comment></comment>