Ask HN: How do I find a job overseas? - <AUTHOR>

Some background:
I am a young software engineer(25) from the US, mostly full-stack web development but dabbling into general needs at my company. I've traveled the US a bit, but I've had little chance to leave the country. While I'm young and mobile I'd like to make the move across the ocean, so that I can cut the biggest hurdle to traveling to far off countries. In particular I was looking into London, so that I could have a home base with a familiar language and culture, but within a few hours flight of most places I want to see.
The issue is that I have no idea how to find a job without moving there first. Unfortunately, I have no contacts overseas to reach out to. I would not be going alone, and we are not in a financial situation to handle move overseas, and handle unemployment for months before finding a job.
Some of the questions that I have, that I have not seen any quick answers to:
1. Do I need a visa or any other special paperwork before applying for a foreign job?
2. Is the cost of relocating from the US too high of a cost for companies to consider me?
3. How do I even go about finding jobs in a specific city like London?
4. Most of my work has been for the government and naturally closed off. I do small side projects when I can, but I don't have any sort of jaw dropping set of open-source contributions. I feel like this has been a hinderance for other jobs that I have applied to, and could amplify the perceived risk as I noted in number 2.
5. I have an additional complication of security clearance, sponsored by my current company. Before traveling overseas I must get it cleared with our security officer. I'm not sure if there are any extra steps I have to take before applying to a foreign company. Obviously I'm a little hesitant to just go and ask him, letting him know that I'm looking to leave the company.
I know that many people on here have gone through similar situations, so any advice or leads would be appreciate, thanks. <comment><USER2> I'm a mid thirties guy from the US originally. I've lived overseas for about 7 years.

I can be a point of reference. First of all, degree really matters overseas. If you have an advanced degree even better (but I would guess that you don't since you mentioned you were 25).

I would avoid Europe at all costs. I have not lived in Europe, but I have traveled for business many, many times. Beautiful, enjoyed the people, and all of that.

Here is why I would avoid it like the plague: 1)EU work permit : slow and painful. 2)Cost of living almost double what you might be paying 3)Tech wages are lower (when you take into account cost of living) 4)Some tech scenes, but they are quite specialized and much smaller than what you would be accustom to in the US. That makes networking much much harder 5)Different countries, different languages which means that nothing scales, so if they want a larger market they have to sell it to an American company. That means the big ideas leave for the US and there are less quality jobs as they are a limited amount of good employers.

I would suggest that you pick another destination. Two that I would recommend personally would be Santiago, Chile and Manilla, Philippines. Cost of living is unbelievable in both. Work permit (if online) is easy to get (as you are not "taking a job from a local"). They both have thriving English communities and excellent cultural experiences. Chile has the mountains and beaches (but a little colder) and Philippines has beautiful beaches.

Both are tech hungry!

</comment><comment><USER3> You are going to have some difficulties because a company will need to sponsor you (IE: work Visa), which costs them much more than a local client.

Why not just find freelance/contracting work? I did this for over a year while I traveled overseas a few years back. If your timezone matches up or isn't that much different, it works pretty well.</comment>


Ruby Is Defined by Terrible Tools - <AUTHOR> http://devblog.avdi.org/2015/07/08/ruby-is-defined-by-terrible-tools/ <comment><USER2> I tend to think that the sophistication of the tools reflect the extent that the language is broken. Valgrind doesn't need to exist for the Java user. You don't need class boilerplate getter/setter generators for Scala. Nobody needs NPE static analyzers for Rust. The need for rename refactoring tools is drastically diminished by the existence of type inference, almost to the point where `:%s/Foo/Bar/g` is entirely adequate.

The non-existence of tools that you find in other languages _might_ signal an immature ecosystem, but it might also signal a diminished need for them.

<comment><USER3> It's been a while since I wrote much Ruby, but I can vividly recall wanting to find the definition of a method and being frustrated at how difficult it often was.

<comment><USER4> > It's been a while since I wrote much Ruby, but I can vividly recall wanting > to find the definition of a method and being frustrated at how difficult it > often was.

Given Ruby's open classes and per-object metaclasses (which are _still_ open), I'm pretty sure a general solution to "find the definition of the method being called at this point in the code" is impossible (and not just, "there is a single correct answer, no general solution is available" impossible, but "there is no guarantee that there is a single correct answer, and even for the subset of cases where there is, no general solution is available" possible.)

<comment><USER5> Ever used Smalltalk, Dylan or Common Lisp commercial tools?

<comment><USER6> Personally, I haven't -- is there a way that the benefits of these tools could be translated into a ruby-based environment? Are such solutions already available? Would be interested to know more.

<comment><USER5> Then this might interest you:

[http://devblog.avdi.org/2015/05/11/in-which-i-make-you- hate-...](http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-ruby- in-7-minutes/)

</comment></comment></comment></comment></comment></comment><comment><USER7> > _And yet, in the early 2000s, long before Rails drove throngs of people to > learn Ruby, very smart people who knew about Lisp and Haskell and good > tooling, fell in love with Ruby. People like Dave Thomas and Martin Fowler > and Jim Weirich._

This is probably because very smart people don't need tools, so they can let themselves fall for the appearance of raw textbook examples of the source code.

Very smart people probably have written programs in low-level languages and gotten them right with only the help of print traces, and raw stack/register dumps.

<comment><USER8> I have no idea whether it correlates with "very smart" in any particular way, and suspect that it probably doesn't, but I have definitely observed significant differences in preference when it comes to the use of extralinguistic tools. It's easy to see how there are some people better suited to early adoption of new languages than others, because they are comfortable with and may actually prefer a minimal-tooling environment, while others will find it so unbearably primitive that they won't be able to get anything done.

I've had coworkers who believed anything that can be automated should be, and therefore one should learn and use all available tools. In this view, anyone failing to take advantage of all possible automation is wasting their time on grunt work and therefore being less productive than they could. One guy at my last job was notorious for his incredibly long and frequently misspelled identifiers; I could not understand _how_ he was failing to notice these problems until I realized that he literally never typed out a full identifier more than once, and typically generated as many bytes of source code via intellisense as he did by typing.

I am out on the opposite end of the spectrum; when I'm coding I don't want to think about tools at all, and a tool had better be absolutely spot-on _perfect_ or its rough edges will waste more of my time by distracting and irritating me than its features will save by automating something I would otherwise have had to do with my brain. I sometimes use IDEs depending on the project, but I always disable code indexing / completion, because the little timing hiccups you get as the tool does its thing break my flow and irritate me. Instead, I put more time into making consistent names and simple APIs so there is less to remember, and do a bit of extra grepping when I can't recall what I need. For me this feels easy and natural; for other people it seems like going the hard way, and they don't understand why I won't let the machine help.

These differences extend all up and down the tool chain; some people love their sophisticated debuggers and write all kinds of complex scripts that produce interesting results, while I tend to just throw in a lot of printfs and debug by reading logs. Not to say I won't use a debugger when it's available - just that I know the log approach will always work, and it can be less work to fall back on something simple that I don't have to think about rather than taking the time to remember where all the debugger's knobs and switches are. On the flip side, I will make heavy use of all available language tools for abstraction and code simplification - lambdas, namespaces, interfaces, whatever's handy, my goal is to build every interface, no matter how minor or internal, in such a way that it's difficult to use it improperly. This has irritated people I've worked with who are happy with simple boilerplate because they rely on automated refactoring tools; to them, these esoteric abstractions were aggravating because it left them struggling to see the forest for all the unfamiliar trees.

Some of this may be a function of experience, particularly experience with low-level environments. I've written plenty of debugging, logging, grepping, and reporting tools over the years, so I know I can always just bang together what I need in the moment, and the prospective payback from learning some existing do-it-all tool feels correspondingly reduced. But is this a smarts thing? I am not so sure - I mean, I do think I'm pretty smart, but it could just be preference; I really like digging into the foundations of things and have therefore invested a lot of time learning how to work in those environments. Someone who actually prefers to live at a higher abstraction level might well be wasting their time by thinking about this sort of thing, and while that's not my bag I certainly wouldn't argue that high-level work is unnecessary or of lesser importance.

Some of it may also be a function of age. I've seen so many tools come and go that it has come to feel like a waste of time to learn one deeply until it has become stable and ubiquitous enough that I can reasonably expect the time I invest in it to pay back over at least 5-10 more years. If it doesn't meet that threshold then why bother? There will just be something else coming along later. I'll learn it if I need to use it, but because of the above-described confidence that I can get the job done regardless of tooling, I'm less likely to hit the bar for "need to use it".

The weakness of the heavy-tooling approach is that tools always have flaws and blind spots, and one can get stuck thinking through the tool's mindset and have trouble when there's a problem it doesn't solve particularly well. But the weakness of the light-tooling approach is that tools shape mental models, and mental models shape language, and software development is really more about communication between humans than it is about communication with machines; if you don't adopt the mental frameworks your coworkers are using it may be more difficult to interact with the systems they are building.

(also, a moment of brag: one of my proudest debugging feats was when I wrote a bootloader for a brand new embedded architecture using no feedback but a single blinking LED. There was no stack trace, not even a serial line for a printf log, because none of the drivers had loaded yet.)

<comment><USER9> Regarding misspelled identifiers, I've experienced the exact opposite problem. Code I had to work with that was clearly written in simple editors often contained misspelled words (though it was also usually written by non-native English speakers) and even bugs arising from using a wrong variable name. Errors that with proper tooling would be near impossible to make, because the tool would immediately underline the variable as either containing a spelling error or not being defined. Not to mention it also lead people to using generic non-descriptive variable names and abbreviations.

I also watched some people trying to printf-debug a problem, and it's usually a fest of "Was the problem here? Hm, not here, ok, let's put these statements over there. Hm, not over there either, what about here... (repeat several more times, depending on how deep the calls go)" Having to do something like this would really feel like stone age to me, when you could just get all the relevant information in one quick pass without having to modify any code.

Another thing is documentation. When you know that you can just bring up a method's documentation with a single keystroke, you are much more motivated to document your own methods in the same way. If it's just "some generator will create a bunch of static html pages later on that most people likely won't ever read", some people will not bother.

I do agree about flaws in tools being a huge issue though. Especially with refactoring tools, if you can't trust it to not accidentally mess up parts of your code, you might as well not use it at all. Similarly, if you can't trust a "find usages of this method" to find ALL of its usages, the utility diminishes severely.

EDIT: oh, and perhaps the most simple, but most important feature of all, being able to Ctrl+click a function to navigate to its definition means that people are going to dive into the code a lot more often, even framework/library code, which is obviously beneficial to learning how things work under the hood. The less friction there is to doing something, the more readily people are going to do it.

<comment><USER10> Why my request for a TL;DR got downvoted? I thought, if you had that much to say, it could be am interesting opinion, but I didn't have enough time to go through it all.

<comment><USER11> I didn't downvote, but I read a TL;DR, especially one directed _at the commenter_ , as saying "my time is more important than yours; could you spend your time purely for my benefit, despite my not being willing to put in my time to read what you've said?" All else aside, it probably takes longer to ask for, and then complain about downvotes on, the request than it does to read 4 short paragraphs.

<comment><USER10> Since when TL;DR's have an obligatory hidden meaning? You can speculate on that, but it's. just your speculation and nothing more and it can be at the compete opposite side of my intentions. So don't tell me what you read in my two words "TL;DR".

There is no way I should justify a request for summary in the first place I just did that afterwards in order to undetstand reasons for downvoting and if that was that someone else is giving their own interpretation to my request, then it's not a valid reason for me.

Their downvote does not make me learn anything new and I just observe how obtuse and flawed their mental process was. They were probably angry for having to read all the long comment I referred to and for not accepting someone else could get away with a shorter version of it. It's called envy and it sucks.

TL;DR:

I don't give a shit about your downvotes if you give your own interpretation to my request in order to support your envy for the fact that I could get away with a shorter version of the original text.

</comment></comment></comment></comment></comment></comment><comment><USER12> Hmm, I'm not so sure about this.

Ruby's tooling is obviously not as advanced as a language like Java, for many reasons. But _terrible_ isn't the adjective I'd use. It's pretty easy to use editor integration to provide pretty decent automatic formatting, linting and code completion. Pry-debugger is pretty great, and generally I don't find working in Ruby to be markedly more taxing that other languages.

I guess YMMV, though.

<comment><USER13> > automatic formatting, linting and code completion

You are describing tooling that is used to _write_ code, but not to read or debug it. And Ruby is exceptionally easy to write without any tooling whatsoever.

The hard problem with dynamic languages is reading the code and understanding what it is doing at run time. And that is where TFA suggests Ruby is terrible.

<comment><USER14> One the way to reading about something else, I read an essay by a language developer complaining about type erasure. In functional languages.

In short, when you get to the point in implementing a language where you can do type erasure, you're golden because it usually means you have things nailed down. Unfortunately then people actually implement type erasure and now there is no way to link data structures in memory with a piece of code at run time.

Or at least very easily.

As an example C/C++ does erase type information. There often being nothing that tells you what an object in memory is. But compilers take great pains to preserve that information in the generated output formats. Which allow you to write debuggers. I'm sure languages like Java and .net do the same.

</comment></comment></comment><comment><USER15> I write both Ruby and Lisp frequently, and I must agree that Lisp tools are vastly superior. Ruby, despite being a dynamic language, has a sorry excuse for a REPL which really hampers my workflow. For example, Rails watches your Ruby files for changes and reloads them in development mode, but if it was easy to re-evaluate arbitrary expressions from your editor (a la SLIME or Geiser) such a feature would never be needed. Then, of course, there's typically so much magic happening that it's often impossible to find the place in which a symbol was defined by searching for that symbol, which makes debugging overly difficult.

<comment><USER16> When you say "sorry excuse for a REPL", you are referring to the built in repl and not pry ([http://pryrepl.org/](http://pryrepl.org/)), right? because pry is freaking awsome!

<comment><USER15> The same issue is there. This is a language issue. I want to edit a file and re-evaluate arbitrary expressions with a keystroke. Writing the code and then copy/pasting it into a REPL prompt is not sufficient. Lisp programmers have had excellent live coding environments for a very long time, but with Ruby I must make do with Rails auto-reloading files for me.

<comment><USER17> > I want to edit a file and re-evaluate arbitrary expressions with a > keystroke. Writing the code and then copy/pasting it into a REPL prompt is > not sufficient.

This suggests to me you've not spent much time with Pry. Are you aware of this:

[https://github.com/pry/pry/wiki/Editor- integration](https://github.com/pry/pry/wiki/Editor-integration)

It's not perfect - doing it perfect with Ruby is a hard problem, as a method can have been defined and redefined in multiple places. But it works very well.

<comment><USER15> >Example: Jump to line 10 in the file, Pry will reload the file after you have finished

It's still just reloading a file. That's not what I want.

<comment><USER17> Then what _do_ you want? The file can be either the original source file, or a file containing _just_ the method you wanted to edit, or anything else.

Why do you think you need more?

<comment><USER15> >Why do you think you need more?

Because I have access to something much better any time I write Scheme.

<comment><USER17> Better in what way? How is it better than a buffer to put arbitrary code in to get executed?

So far, from what you've pointed at, you seem to have picked the most restrictive simplistic examples of what Pry is capable of as a counter-example to explain why it isn't enough for you, rather than explain what it is you believe is actually missing.

Point is: You have access to much better than the examples you've pointed at with Pry as well.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> I wrote a Smalltalk-esque System Browser for manipulating class definitions without the need for a filesystem awhile ago (here's a rather crappy screencast of it: [https://www.youtube.com/watch?v=2xC5B5t5Rq8](https://www.youtube.com/watch?v=2xC5B5t5Rq8))

It was a LOT of fun, and I wish I had the time to resume it. The feedback loop was so much faster, and I can say that there is serious cognitive overhead we all carry by manipulating the definitions of things in files rather than just the objects and classes themselves.

It was a fun experiment.

</comment><comment><USER19> This is one of the things I've always liked about JRuby. You can use the excellent tooling of the JVM ecosystem (e.g. YourKit, Coverity Dynamic Analyzer) to understand the behavior of your JRuby applications, and even attach directly to running production apps to debug them.

I've found tools like this essential for debugging multithreaded JRuby applications, and there's simply nothing else like them available for MRI.

</comment><comment><USER20> How would people that use both Python and Ruby compare the tooling for both languages? I only am familiar with Python, and I end up using IPython most of the time. I'm curious whether I'm missing out, or maybe Python also has "terrible" tooling..

<comment><USER21> This is pretty specific, but Ruby has pretty terrible support for parsing Ruby. Libraries are either unmaintained or broken or for old versions. Python is great for parsing ('import ast'), compiling ('compile(...)') and executing ('exec(...)'). So it's much easier to write code generators, write linters and autocompletion tools and such.

<comment><USER22> >but Ruby has pretty terrible support for parsing Ruby

[https://github.com/whitequark/parser](https://github.com/whitequark/parser)

Neither unmaintained, broken nor just for old versions. It has some really minor incompatibilities though:

[https://github.com/whitequark/parser#known- issues](https://github.com/whitequark/parser#known-issues)

The same person also wrote a Python parser because apparently the ast module doesn't provide precise location information of tokens:

[https://github.com/m-labs/pythonparser](https://github.com/m-labs/pythonparser)

</comment></comment></comment><comment><USER23> One of the biggest success stories in recent times where language support has made tooling awesome is JSX.

The success of JSX shows that developers are happy to write HTML inside code, and there are clear benefits of doing so compared to using a dedicated templating language. But the reason why this wasn't popular till JSX showed up was that it is impossible to parse the HTML built in code through string munging. JSX makes XML-inside-Code parseable, which makes it possible for us to use IntelliJ's excellent IDEs to work seamlessly with it.

<comment><USER24> For those confused:

JSX is a statically-typed, object-oriented programming language designed to run on modern web browsers. Being developed at DeNA as a research project, …

[https://jsx.github.io/](https://jsx.github.io/)

<comment> a-priori I think the parent is actually referring to this JSX:

[https://facebook.github.io/react/docs/jsx-in- depth.html](https://facebook.github.io/react/docs/jsx-in-depth.html)

</comment></comment></comment><comment><USER13>
      > People in the industry are very excited about various ideas that nominally help you deal with
      > large code bases, such as IDEs that can manipulate code as "algebraic structures", and search
      > indexes, and so on. These people tend to view code bases much the way construction workers view
      > dirt: they want great big machines that can move the dirt this way and that. There's
      > conservation of dirt at work: you can't compress dirt, not much, so their solution set consists
      > of various ways of shoveling the dirt around. There are even programming interview questions,
      > surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck
      > at a time.

      > Industry programmers are excited about solutions to a big non-problem. It's just a mountain of
      > dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not.

      > My minority opinion is that a mountain of code is the worst thing that can befall a person, a
      > team, a company. I believe that code weight wrecks projects and companies, that it forces
      > rewrites after a certain size, and that smart teams will do everything in their power to keep
      > their code base from becoming a mountain. Tools or no tools. That's what I believe.

—Steve Yegge, "Code's Worst Enemy" [http://steve- yegge.blogspot.ca/2007/12/codes-worst-enemy.htm...](http://steve- yegge.blogspot.ca/2007/12/codes-worst-enemy.html)

I'm not quoting this to refute the idea that Ruby has terrible tooling, or to suggest that tooling doesn't matter. But rather, to give some context for this idea:

When we first embraced Ruby, we were writing web apps in Java. Ruby allowed us to write those same apps with fewer lines of code, by fewer people, in less time. That was a triple-win, and there were all sorts of secondary positive effects.

Fewer people on a team means less necessary process. It means less money required. YCombinator wouldn't exist today if you couldn't have done something meaningful with $18,000 over a few months. Less time means you can be lean and iterate, rather than spending time and tons of money trying to analyze what a market wants in advance.

Those factors were massive wins for the startup culture. There are similar effects within companies, but I needn't list them out here.

But one negative effect is that with small teams writing fewer lines of code, in a startup culture, there is much less emphasis on tooling. It's a "nice-to- have," because app complexity does not make the difference between shipping and not shipping.

So yeah, there's some tooling, but it is not very good. Really, it's not. But it was good enough.

But as time went on, our apps and teams grew. Most businesses are in a Red Queen's Race against their competition. It is very hard to stay small and focused and have a single responsibility in a market. So our code grows and grows, until it reaches a kind of equilibrium with how many lines of code a company can support. Which means we expand until we're back to having big code bases, with many engineers.

And guess what? One million lines of Java is easier to understand than one million lines of Ruby. Doubly so when you have better Java tooling than Ruby tooling, and when Ruby does things that demand better tooling.

So now we're in this place where successful companies have big apps, but we don't have a "big app" culture, so we don't have the tooling required to support this many lines of Java, much less this many lines of Ruby.

\---

p.s. Here's a very nice person saying the same thing at WebRebels: [http://vimeo.com/76141334](http://vimeo.com/76141334)

<comment><USER25> I don't disagree with the thrust of this post, but

      > When we first embraced Ruby, we were writing web apps in Java.

Avdi's reference to people coming to embrace Ruby is specifically in the pre- Rails time period. So you're talking about different, though absolutely connected, things.

<comment><USER13> I was there too. You know... It was possible to write web apps in Ruby before Rails and Sinatra, although today that feels like a party trick, like writing FizzBuzz in Lambda Calculus.

<comment><USER25> Pssssh. :)

Anyway, I'm hoping that the new static typing proposals can help make Ruby's tooling better. Ruby's greatest strength is also a huge weakness, it's just so hard to tell what's happening with all the dynamism. As someone who's been back to static typing for a while, but wrote a lot of JavaScript over the past few weeks, that's the angle I've been thinking about in this area.

I haven't been able to properly articulate why I never feel the need for these tools in Ruby, yet in other languages, they feel indispensable. Human brains are amazing: you can hold two completely contradictory opinions simultaneously. (Though maybe the different context means that they're not actually contradictory, even if it feels like it)

<comment><USER4> > Anyway, I'm hoping that the new static typing proposals can help make Ruby's > tooling better.

Probably not. Keeping the language in place and focusing on tooling would make the tooling better; as others have pointed out, there are dynamic languages with better tooling.

And, its not like people who want the costs and benefits of static typing are ill-served by the current marketplace of computer languages.

</comment></comment></comment></comment></comment><comment><USER26> The author touches on something important when comparing Ruby to Unix, and why we love them more than more structured systems.

 _Rigorous language is the enemy of expressive language._

That's not to say you can't be expressive within a rigorous system - it's just more difficult. And you can only express the things that the rigorous language is capable of expressing. So less rigorous, less formal environments, like Ruby and Unix, allow for a great deal of fast and intuitive expressiveness.

<comment><USER27> > Rigorous language is the enemy of expressive language.

That's an interesting statement. I couldn't find it on the web, is this your own, or a paraphrasing/translation?

<comment><USER26> Yeah, I just made it up.

</comment></comment></comment><comment><USER28> I don't know, if the statement is true, since I did not work with Ruby really till now.

But I definitively would support this statement:

> Programming languages cannot be considered separately from their ecosystems

I think, one of the main reasons for the success of the C system was not the language itself, but the standard C library. Standard Pascal did not have such a thing (Borland Pascal had and was more successful as any other Pascal), Modula 2 -- a superior language at its time, did not have it (the library that was standard for Modula 2, was just to clunky for wide usage) and also other languages did not have it.

C, when it started, had not only the library, but also a -- for that time -- superior development environment: Unix.

From this, I would strongly agree, that the ecosystem is decisive -- and the bar has risen since the times of C. Today, you need top compilers or interpreters, top of the notch libraries -- best to have a framework (like Rails) for a good use-case to use the language and tools around that support your programming.

With all those good languages around today, any new language must have an appeal and the ecosystem and if possible the community, to be successful.

<comment><USER5> I came to view UNIX as the actual C runtime, they just decided to split it up into ANSI C and POSIX standards.

</comment></comment><comment><USER29> This argument rings true and has been in the back of my mind for quite a while. To take this into a different context... for example if you were building a house per se.

Houses were built out of wood for years (and still is), but we slowly built tools to make it easier (Hand held saws, levels, nail guns). Now a new material has hit the market... plastic (for instance) and it is a better and more pliable medium to build a home, but we lack the tools to make it easier. It is as though we have no hand tools that will cut through it, or no nail gun that will penetrate it. Yes, it (Ruby) seems to be a better material to have a structure built with, but when you are building a lot of homes or even a mansion, it seems silly to use a material that limits what you can do to manipulate it. The argument that "Ruby is so cool, I don't need tools" seems quite silly and misguided. That may be OK if you are building treehouse in your back yard, but if you are building an entire housing district, you are going to lose money in the development costs.

<comment><USER26> The best quality, long term lowest cost roofing material is copper. But we use asphalt shingles, which are short-lived and expensive in the long term. Why? Because they're cheap in the short run, they require little expertise to install, and they're easy to customize.

Sound familiar?

</comment></comment><comment><USER30> So what's a language that has much better tooling than ruby, but still has a web stack as good as Rails? Does one exist?

<comment><USER31> Some people would say "Python", since the tooling for Python is generally excellent, but I don't have enough experience with Python web stacks to say that they're better or worse than Rails. There's certainly less _" magic"_ with Python, but I'd argue that's a good thing.

<comment><USER32> I think all the criticism from that article applies to Python as well.

<comment><USER33> Not all of them. Python is often stricter in some aspects of the language and in community norms.

Someone can correct me if I'm wrong but the module namespacing helps mitigate this complaint via Twitter:

> Can't figure out how a simple thing works in a codebase with a zillion tiny > objects and a billion levels of indirection?

i.e. unless you've gone out of your way to be too clever - you usually know where things in the current namespace came from.

</comment></comment></comment></comment><comment><USER34> So wrong. The author has probably never tried RubyMine (or IntelliJ with the Ruby + Rails + etc. plugins).

I was hacking with Pharo Smalltalk just yesterday, so I get what the author means by the niceties of Smalltalk, but Ruby tools from Jetbrains are very nice.

<comment><USER35> Please read the article before posting. He mentions rubymine.

<comment><USER34> Thanks for the correction! I missed that he relies on Rubymine for his work.

</comment></comment></comment><comment><USER36> > "In Smalltalk, everything happens somewhere else." \- Adele Goldberg

Am I the only one that thinks this sounds like a maintenance nightmare?

I don't understand how this could ever be a good thing.

<comment><USER37> It can be beneficial for maintenance as it helps avoid overly-large methods and monolith objects.

</comment></comment><comment><USER38> EDIT: I realize I left out my main point: I definitely agree with several of the points in the article. I have long wished for some way to traverse ObjectSpace easily and to know what code is being actually executed at any point in time. Lack of use of or availablity of comprehensive static analysis tools in our programming today is a huge problem, IMO. </end edit>

I don't have much experience with Ruby debuggers, as I rarely use them.

I do use RubyMine, every day. It's got powerful inspections and is an incredibly valuable tool for me. But, I originally used IDEA many years ago, and I don't think that RubyMine is anywhere near as powerful, because of all the dynamism inherent in Ruby.

I personally think that Ruby is far too flexible a language. I use metaprogramming, monkey patching, and `method_missing` exceedingly sparingly, if at all. I try to never make code any less traceable than possible. But, I use Rails, and while I don't dive into the Rails source very often, I'm sure there's a lot of hidden stuff in there. All sorts of methods added to classes (ActiveSupport - inflections, time zone helpers, ... - and all the core extensions that have made their ways into gems that do not even require ActiveSupport), and all of my URL helpers which use method_missing to "define methods" that never existed. In a word, Ruby's dangerous (and can be made to be very hard to reason about).

I have been watching [http://crystal-lang.org/](http://crystal-lang.org/) every once in a while. I think one of the core strengths of Ruby is how concise and elegant it is or at least can be, and how readable it is or at least can be. It's pretty damn nice in a lot of ways. The community support is of course incredible as well ([https://github.com/bbatsov/ruby-style- guide](https://github.com/bbatsov/ruby-style-guide) is great, [http://slim- lang.com/](http://slim-lang.com/) has made markup a non-arduous task, etc). Maybe we can do better.

EDIT: Incidentally: a lot of my complaints about Ruby are things that I would say about JS as well, but I have considerably less experience there. I just know that I've half-learned sooo many JS patterns. While I don't know Python, one of the things I've really liked hearing about it is how there's supposed to be "one right way" to do stuff. I think this is good. Code serves a purpose, it's a functional tool - IMO, it's not like written language where you really need a bunch of similar-but-different ways to get the same meaning across.

<comment><USER39> The Python "one right way" is a bit of a myth. It's a design goal that is unrealizable in practice. However, the documentation is very good and (in my experience) it lends itself to solving problems in very obvious ways.

<comment><USER38> Thanks. I had my suspicions, but some things are best left to the imagination :)

</comment></comment></comment><comment><USER40> For a second I thought that subtle background on the site was actually something physically happening on my screen.

</comment><comment><USER10> everything within our knowledge in the material world can be fixed with enough resources. maybe for Ruby you could need more resources at the beginning given how it has been designed, but once you build up a good land upon which it will be easier to make other changes, (possibly even with a Kickstarter for a new kickass ruby implementation?) then the resources required for other changes will be comparable with the same needed in other languages. In the meanwhile in Ruby we have been profiting from nice syntax and object model, which in the end, IMHO is what paired the balance and still made us use it. This article was great in the sense that highlightinged the right approach that we would need in Ruby to make it grow to a "state of the art language". I really hope this will happen but for some reason I feel a great amount of opposing force to it and I am not sure it only comes from rational thought. I'd like to see someone have their say on this aspect at a deeper level.

<comment><USER10> Refactoring my own comment above (I apologize but I can't delete it anymore).

Everything in the material world within our knowledge can be fixed with enough resources.

Given the current design, maybe for Ruby we could need more resources at the start of this process, but once a good base is layed out it will be easier to make other changes. Or could it all start with a Kickstarter for a new Ruby implementation???

Anyway, at that point, the resources required for successive changes will be comparable with the same needed by other languages.

So far in Ruby we have been profiting from nice syntax and object model, which in the end is what paired the balance and still made us use it.

This article was great in the sense that highlightinged the right approach that we would need in Ruby to make it grow to a better implementation. I really hope this will happen but for some reason I feel a great amount of opposing force to it and I am not sure it only comes from rational mindset. I'd like to see someone have their say on this on a deeper level.

</comment></comment><comment><USER41> The hipster backlash on Ruby continues.

<comment><USER42> Considering that the author's primary source of income (to the best of my knowledge) is a video series on tips and tricks for Ruby development, I wouldn't chalk this up to "backlash" so much as "call to arms".</comment></comment>


Dropbox is down - <AUTHOR> http://scripting.com/stories/2010/10/05/dropboxIsDown.html <comment><USER2> For me, Dropbox.com is up but scripting.com is down.

I believe this is one of those rare circumstances when I can use the word "irony" correctly.

<comment><USER3> Dropbox.com is up, sure. The service is down though.

</comment></comment><comment><USER4> Hey...they at least posted something. I love when companies communicate that they are down rather than just stonewalling.

In this day and age when systems are ridiculously complex I expect stuff to go down every so often. It is how they handle it that counts.

<comment><AUTHOR> Totally agree. And the community responds quickly too.

</comment></comment><comment><USER5> Use this link to keep an eye on things: <http://status.dropbox.com/>

<comment><USER6> Yikes. They are doing it wrong.

This is the classic case of "working hard to fix things when they should be spending a little more time updating clients and being descriptive about the problem."

I've been involved with so many down-time instances with web hosts and web service providers that I can tell you the #1 thing that pisses people off is the lack of communication - MORE THAN THE DOWNTIME ITSELF!

If they could tell us some technical, but not too revealing, details, that would be great. Then those of us with experience can guess what the time frame will ACTUALLY be to fix the problem, while others can at least get the feeling that they getting to the bottom of the problem.

<comment><USER7> I'll be the contrary voice. At this point, I don't really care what the cause of the downtime is and I'd prefer that their engineers are working full time on fixing it, rather than writing extended blog posts about it. If they have a solid ETA on a fix, that might be nice to know, but from my experience it's unusual to be able to give such a number with confidence. After the fact, maybe there is an interesting story to tell about what went wrong and how they hope to avoid it in the future, but that's for tomorrow not today.

<comment><USER8> I'll go in the middle.

First having a page like this where I can make sure I'm not the issue is helpful and I can be somewhat comforted there.

However, now that I've discovered the issue doesn't exist between my ass and my keyboard I'd also like some sort of idea on the depth of the issue and a timeframe for a fix.

<comment><USER9> I think your porridge is just right.

Don't make me read a wall of text to get a simple answer to "is it down?", but clue me in on what's going on and, if possible, when I can expect service to resume.

Dropbox isn't critical for us where I work, but it is something we use daily for passing documents around.

</comment></comment></comment></comment></comment><comment><USER10> Still down for me. You can get status updates here:

<https://twitter.com/#!/dropboxops>

</comment><comment><USER11> They're Up Now: <http://status.dropbox.com/> 11:55 pst

</comment><comment><USER12> I would be interested to know how this is a 49 point worth submission

<comment><USER13> It highlights the dangers of the cloud as people move more and more "mission- critical" applications to the Web.

<comment><USER14> Calling a service going down a "danger of the cloud" is sensationalist, like calling any pervert who has ever touched a keyboard an "Internet predator." The adjective 'Internet' in that case, or 'cloud' in this one, does not usefully divide the problem space.

Your service will have the same amount of unpredictable black-swan downtime whether it is local or remote. The difference is, when the only person you have to blame is yourself (or someone you empathize with), you mentally downplay the downtime—whereas, when you can point a finger and create a mental "us/them" division, you exaggerate it.

</comment></comment></comment><comment><USER15> scripting.com is down

</comment><comment><USER16> I very much consider Dropbox one of the very best when it comes to communicating and solving issues. Wouldn't worry to much.

</comment><comment><USER17> 1and1.com is down today <http://twitter.com/#search?q=1and1>

<comment><USER18> I've had constant issues with 1and1 over the years with their less than reliable uptime. At least one of my sites (which are relatively low-traffic sites) goes down once a week for an undetermined amount of time.

Has anybody had better experiences with other hosts? I've been thinking of trying out Linode lately..

<comment><USER19> I just came into a position where I inherited a site running on 1and1. Yesterday their DNS went down for a half an hour, that was a fun half hour.

I've never really had problems with HostGator or asmallorange. HostGator can be slow, but it's good value for the price, and pretty clean cpanel interface on the whole. ASO has good support and seems pretty snappy. (Of course I'm using an absurd amount of disk space on HostGator, mostly for backups.)

The biggest thing with 1and1 is what a huge mess their administrative interface is. Almost half of the space is ads trying to upsell you to their other services. You would think as a paying customer they could leave me alone.

<comment><USER18> It's both good and bad to see others are sharing my experiences. And yes, their admin interface is absolutely horrible.

Thanks for sharing!

</comment></comment></comment></comment><comment><USER20> Already working again for me.

</comment><comment><USER21> Works for me, oddly enough.

Rolling blackouts, eh?</comment>


Maintainable ETL Practices at Stitchfix - <AUTHOR> https://multithreaded.stitchfix.com/blog/2019/05/21/maintainable-etls/ <comment><USER3> Huge +1 to leveraging SQL as much as possible during ETL.

We recently moved our data warehouse to Snowflake. Along the way, we adopted an ELT paradigm instead of ETL, where you load your raw data into the warehouse and then perform any transformations in the warehouse. A tool called dbt ([https://www.getdbt.com/](https://www.getdbt.com/)) has made this a joy. You write SQL select queries in SQL files, and dbt creates a DAG based on this SQL so it can efficiently create tables/views in parallel. dbt also comes with some nifty testing facilities to validate your data once it is transformed.

This is a great article, thank you for writing it!

<comment><USER4> I am not a big fan for the term ELT

Just because you are using a database as your work space doesnt mean you Load your data before transformation

Most complex dw, have multiple layers of transformation, and several workspaces along the way

There is always a final step where you load the clean data, into your clean schema, used for querying the data

ETL

        Extract = Fetch the data you want
        T = Make all necessary change
        L = Create a clean copy

<comment><USER5> ETL can include the destruction of raw data between the T & L. ELT assumes it is retained. This is a legacy from days when storage was expensive and it often wasn't tenable to retain everything.

<comment><USER6> We held onto middle data when I worked in ETL 15 years ago. It's normal to save data in the middle for unit testing and lookup tables. I agree with GP this doesn't need a new term.

</comment></comment></comment></comment><comment><USER7> In discussions like this, I often wonder how there can be enough data to require a "big data" pipeline with things like Spark and Presto.

Stitch Fix seems to be one of those online services that send you sets of clothes that they think fit your style. That seems like a really narrow, low- data kind of industry. How much data can they possibly have? And why so big on the backend? In January 2018 they had 100 engineers. Presumably they're even larger now. Just for a service that sends out clothing.

Maybe I'm lacking in imagination or insight into what takes to run a company like this. On the other hand, a single PostgreSQL instance can run complex ad- hoc queries, with CTEs and everything, on a single node involving millions, even billions, of rows.

<comment><USER8> Their service is high-touch. Stylists speak with clients constantly, so they record this information.

They also have mobile apps, they run product experiments, they source and sell clothing and manage inventory, they build and iterate on algorithmic approaches to recommend and design clothing (many of which help stylists and never reach the screen of an external client).

You can skim through their Algorithms blog for some more detail. I find them impressive in how they scale the impact of relatively few stylists to about 3M users.

[https://www.kleinerperkins.com/files/INTERNET_TRENDS_REPORT_...](https://www.kleinerperkins.com/files/INTERNET_TRENDS_REPORT_2018.pdf)

</comment></comment><comment><USER9> Too large a chunk of my life was burnt the ETL from hell. Other than SQL, I can't see any other tool that would have helped.

I found the easiest way was just dump tables of data into long varchars - <USER2> the supposedly numeric stuff, because often enough it wasn't - then scrub & filter it from there. (NB, if you take anything from this post, make it that).

There were multiple challenges, but one that was most painful was the sheer filth mixed into the data. Too often even a human couldn't work out what the heck was supposed to be in some field. Often we could, but it ate a lot of time.

It doesn't sound like you ETLs are anything like mine; you start with pretty clean data. You are lucky.

<comment><USER8> Yikes, I'm sorry. What were your application developers doing to persist this messy data?

<comment><USER9> It was an upgrade from a legacy system to its successor. I never used the legacy system so I don't know what checks they did. I suspect little to none; I guess they pretty much exposed the raw 'tables' to the user to insert whatever they wanted.

I wrote 'tables' because it wasn't a relational DB although the successor system was.

The amount of data was pretty minimal too, not much more than a dozen GB, but it ate up at least 4 man-years to convert. I still cringe thinking about it. Some parts were an interesting challenge but mostly just soul destroying grind.

</comment></comment></comment><comment><USER10> "The primary benefit of SQL is that it's understood by all data professionals: data scientists, data engineers, analytics engineers, data analysts, DB admins, and many business analysts."

No, the primary benefit of using SQL is not SQL itself but the "free features" you get with the RDBMS you're using. Enforcement of primary keys, automatic data type conversions, free transactions! and rollbacks ... and the sheer gift that is set-based operations on large chunks of data. It is just plain stupid to want to code the transformations or insertion of millions of rows iteratively than to rely the implicit rollback power of an INSERT statement.

Rule # 1 in my projects: Avoid getting sexy in code, use the RDBMS for all transformations post staging. Always stage to RDBMS "as is" (data warts and all). Cleanup with SQL and stored procedures. This way you can SQL query the whole original format and figure out the best cleanup and transformations needed.

</comment><comment><USER11> One comment is CTEs don't use indexes, so you may want to avoid using them in production code. That's something to consider if you may need to port code to/from databases where indexes may be available.</comment>


Blackphone 2 Review - <AUTHOR> http://arstechnica.com/gadgets/2015/09/paranoid-android-redux-going-dark-with-silent-circles-blackphone-2/ <comment><USER2> I can not be the only one whose faith in secure digital has been fundamentally and irrevocably altered in light of the past few years. In my estimation, anything that has been said or typed in the proximity of a connected digital device is compromised. There are just too many attack vectors.

I imagine if you had enough realtime keystroke data, you could even identify a user using nothing more than how they type on a keyboard. That's some scary stuff.

Privacy advocates would better serve the public if they instead educated people on how to communicate securely instead of producing yet another black box that users can blindly put their trust in. I suppose this is better than nothing when dealing with less capable actors, but for those who plan their future years ahead, doing something on this phone, only to have it bulk collected and stuck in a database for decryption and analysis later when it serves the political will of those in power is counter productive.

<comment><USER3> "I imagine if you had enough realtime keystroke data, you could even identify a user using nothing more than how they type on a keyboard."

And what they typed - acoustic snooping.

[https://freedom-to-tinker.com/blog/felten/acoustic- snooping-...](https://freedom-to-tinker.com/blog/felten/acoustic-snooping- typed-information/)

</comment></comment><comment><USER4> So NSA is now going to intercept each shipment of Blackphone cellphones to bug them like they did with network equipment?

[http://arstechnica.com/tech-policy/2014/05/photos-of-an- nsa-...](http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade- factory-show-cisco-router-getting-implant/)

The problem is that who orders a Blackphone is not completely private and it is a sign that those people have something they want to hide and there isn't that many of them.

You almost need a private way of sending Blackphones so that the NSA doesn't know who is getting which phone and then if there is a enough volume of Blackphones you should be okay.

<comment><USER5> /dawns tinfoil -- I ordered a router a few weeks ago. Big upgrade for me from a refurbished buffalo ~$30 several years ago to a $200 quad antenna multi- channel 2gb sex machine. The package though shipped in the states got delayed in route do to "customs" I was informed. Took a few days before it was back on the road.

Should I be worried?

<comment><USER6> _dons tinfoil_

<comment><USER5> touché

</comment></comment></comment></comment><comment><USER7> there are a few issues on things like this; for me.

1) This phone's security features tend to rely on other people having the same phone, which is definitely not a guarantee I can make.

2) This phone (perhaps only this article) doesn't go into detail about how it was secured only that it "was deeply secured" which is too vague for a technical audience.

3) It relies on central services provided by the manufacturer; (why not use Telegram? at least telegram is cross platform).

4) By ordering this phone, it's telling people that I value privacy, which could make me a higher priority target for those that are breaching privacy on a massive scale.

This device does not enhance my privacy, but it gives me all the inconvenience. Now I'd have /another/ user account to worry about and /another/ program to get people to share their details with.

when I think of security I think of PGP (yes, I'm aware the CEO was a producer of PGP) and things like SILC- where it's controlled by users and verified by people you'd like to confer with.

<comment><USER8> 1) They have software for other phones and desktop computers. Others can use those without having to buy Blackphone. Assuming the hardware does confer some security advantage, talking to people who just have the software won't negate the security advantage gained for communication between users do have the hardware.

2) Fair point.

3) Telegram is also a central service, so in that respect it's no better than Silent Circle. WhisperSystems is better in that they make some server source code public. But to be fair to Silent Circle, their offer is much more complete: Voice, Messaging, Encrypted contact storage, and outbound PSTN access.

4) By using SILC, Tor, or GPG broadcasts the fact that you value privacy, which could make you a higher priority. What are you going to do, just send everything in cleartext and hope nobody looks?

<comment><USER7> 1) I was not made aware of this, but that's good.

3) my point was that telegram was "no better" but has better market penetration, while being essentially the same thing.. why have more standards.

4) this is also true, but it's less real world advertising of that fact, you don't order tor, you don't order GPG, and you don't have a physical device which proudly announces that you do. If you're doing security online right, nobody can tell you're doing it at a glance.

<comment><USER8> 3) Leaving aside the lack of voice support in Telegram and considering only messaging: Both SCIMP (Silent Circle) and TextSecure/Axolotl (WhisperSystems) are better protocols than MTProto (Telegram).

4) You order a privacy tool from Amazon, and you're put on a list. You emit the kind of encrypted traffic that 99% of internet users don't, you also get put on a list. In most cases, there's no difference. I suppose if your threat model requires you physically appear not to care about privacy then it matters. Like maybe you work in a sensitive position and you don't want anyone to think you might exfiltrate data, so you only carry the work provisioned device which logs everything you do.

<comment><USER9> 4) Yeah, it's such a massive shame that Android/Google doesn't have end-to-end encryption between all users enabled as a default, like iOS has with iMessage.

</comment></comment></comment></comment></comment><comment><USER10> But does the (closed source, buggy) baseband processor still have unfettered access the the main CPU's memory?

<comment><USER8> Blackphone doesn't appear any better than an average Android in that respect. As far as I know only GSMK offers any countermeasure to protect against compromised or malicious baseband, and even their solution isn't ideal.

</comment></comment><comment><USER11> I don't understand how they can include Google's app ecosystem and still claim to be privacy-oriented. Google Play Services is basically a firehose of information straight to Google.

It seems to me like setting up your own disk encryption and secure SIP calling on a phone with an AOSP ROM without any Google apps installed (and just using f-droid as your app store) would be far superior to using this device as far as privacy goes.

</comment><comment><USER12> Still no hardware switches for radios and such...

<comment><USER13> "Still no hardware switches for radios and such..."

Excellent point. A secure phone should either have a GSM module that can be removed or a hard switch to disable it.

</comment></comment><comment><USER14> Is there any reason for me to trust the hardware?

</comment><comment><USER15> I like the idea of virtualized phones and spaces. No system is completely secure but this one looks miles ahead of anything else in the smartphone space I've seen. I want one but have to wait for the international version (assuming US version is not same bw as EU).

</comment><comment><USER16> Blackberry Priv will have a Grsecurity hardened kernel. Why doesn't Silent OS have that yet?

<comment><USER17> While I got excited about this at first, after spending some time on the crackberry forums, it seems the main intention of using grsec is to prevent rooting, not necessarily to protect the user. So that means no cyanogenmod or replicant, and users will be stuck with whatever custom bloatware/spyware blackberry decides it should have.

All I really want is a fully open source phone that I have control over, is that really too much to ask?

<comment><USER13> "All I really want is a fully open source phone that I have control over, is that really too much to ask?"

An open baseband is the missing piece and that appears to be rocket science.

If only someone would leak the specs of a modern baseband the same way calypso was leaked ... anyone ? Anyone ?

</comment></comment></comment><comment><USER18> Secure text communication between mobile devices has been around for a _long_ time... It's called BBM.

<comment><USER19> Depends on your definition of secure - last I heard, default BBM was still using a globally shared key and logging your messages; BB has on several occasions handed messages over to governments at request (such as during London riots etc).

BBM is only secure in combination with a self-hosted BES server (and on which you have installed your own CA certs).</comment></comment>


Ask HN: How to prep towards becoming a hardware robotics engineer? - <AUTHOR> N/A <comment><USER2> You'd get better answers if you said what your background is, and what kind of robotics hardware you want to work on.</comment>


Ask HN: Should I get the iPhone 11 Pro or a pocket camera? - <AUTHOR> For the last years, I have been using a cheap Android phone for $200 or so and I am completely happy with it.
However, I have the feeling that the iPhone 11 Pro might enable me to make nicer photos. So I am playing with the idea to get one. I would probably not even use it as a phone. Just as a camera.
Does that make sense? Or are there pocket cameras that weight as little as the iPhone 11 Pro and make better photos? <comment><USER2> Buying an iPhone 11 Pro and not using it as a phone would be ridiculous. It's designed under different constraints.

The image sensors are tiny compared to good cameras. More photos hitting the sensor means less need for computational imagery.

The battery in a phone is one day only. A camera's battery will outlast that 5-10x, and you can carry a replacement battery.

Having a focus ring, dials to adjust ISO or aperture or shutter speed, means you can capture challenging shots, where with a smartphone, you point and pray. "Pro" adjustments are with finicky on-screen widgets, that you may not even be able to see in bright daylight or from glare.

If you buy a big DSLR, though, realize it's a hassle to drag it around. If it doesn't fit in your pocket easily, you may not bring it with you, and you can't capture a moment when you don't have your camera with you.

</comment><comment><USER3> I think if you didn't use it as a phone too that wouldn't make much sense to me. Whether you want a DLSR, range finder, travel compact... I can think of various models that would be better standalone cameras.

X100F, rx100 series, Ricoh G3 or X system Fuji come to mind.

That said, I think a phone can be a great compliment to a camera. I have a camera I use mostly on holidays but have a moment fish eye on my phone for indoor architecture shots. I'm considering the iPhones 120° wide as a replacement for my phone and moment superfish but not my camera. I really enjoy the physical controls for aperture and ev compensation.

<comment><AUTHOR> Say I go with the Ricoh GR3 - what would be the benefits over an iPhone?

I can think of a number of downsides:

It's much bulkier.

It's a bit heavier.

The screen is much smaller.

Organizing and browsing photos is probably not as good?

It probably has no photo editing.

It cannot send the photos via wifi to my laptop.

I cannot directly upload the photos to facebook etc.

<comment><USER3> I have a USBC to as card reader. I don't expect my camera to edit photos. Perhaps that's too much hassle for some but it works well for me. You can also transfer wirelessly.

It has a 24mp sensor and a 28mm equiv so you don't have the three lenses bit with crop zoom it's pretty versatile.

It does have a touch screen if you want that. (Never really wanted this myself)

It has a built in ND filter. My camera has this too and it's a feature I really value. (large aperture in bright daylight and long exposures etc)

It's cheaper.

 I think choosing a camera is a really personal decision. Only you know how your factors rank. Better for me might be worse for you (e.g. no touchscreen please)

</comment></comment></comment><comment><USER4> Buying an iPhone 11 just for the camera is a rather expensive exercise. Whilst you can buy a rather good DSLR for the price of an iPhone it will be far bulkier and not have the same level of advanced features.

Having said that, some Android phones, especially those at iPhone level prices have very good cameras as well. In my experience an Oppo R2 outperforms a Canon EOS-1000D.

My biggest gripe with smartphone cameras is that they are too wide-angle. Digital zoom simply trades pseudo-telephoto capability for resolution.

</comment><comment><USER5> I wouldn't bother just for the camera.

The Huawei P30 Pro,for example has an astonishing set of cameras on it - and I often use it as a companion to my "proper" camera.

Though for me at least, the biggest thing that keeps me using an actual camera is the tactile nature of the controls.

I think you would struggle to find one as light as iPhone but maybe take a look at models like the Ricoh GR3, any of the Fuji X series cameras (disclaimer, I have an XT3 and an XT10) or if you are feeling spendy, the Leica Q</comment>


Ask HN: Languages for safety-critical embedded work? - <AUTHOR> I'm interested to hear from the HN crowd what's out there in terms of languages / frameworks for doing safety-critical embedded development on commonly-available hardware like the ESP8266.  Think at the safety level of implantable medical devices or flight control software.<p>My usual Google skills aren't getting me anywhere on this one :) <comment><USER2> 1\. If you are developing for the ESP8266, your current choices are C, Lua, and Arduino. So you are pretty much using C by default.

2\. The automotive industry has a standard for safety critical C code. It's called MISRA C. A few of the rules are stupid, but others will save you worlds of issues. You have to buy the PDF from the committee's website for about 15 bucks, but it's worth reading and mostly following.

3\. If you are actually writing medical or flight control software, you cannot depend on a single proccesor or computer. Perfect software is not enough. Airliners have three separate computers, each containing three different processor architecture processors, each processor running code compiled on a different compiler, and all checking each others work. SpaceX runs at least five separate embedded linux computers for any critical systems. These communicate in such a way that they can tolerate even malicious actions by any two computers. Google "byzantine fault tolarance"

<comment><USER3> I fully agree with your analysis of MISRA C.

The issue I have with it is that some people seem to be refusing using their brain when following rules. For exampe, MISRA static checkers compain if you do:

      x = 250

So I've seen people do:

      #define TWO_HUNDRED_FIFTY 250
      x = TWO_HUNDRED_FIFTY

And it drives me insane that people see some rules but don't actually understand what they're for and just skirt around it in the stupidest way possible.

<comment><USER4> Well, it's a stupid rule. There are times when a plain old number is more maintainable. You don't have to name it, you don't have the extra line of code, you can immediately see what the number is, etc.

<comment><USER3> I disagree. There are a few cases where a number is more expressive - I even think MISRA has exemptions for 1, 0 and FF.

But in most cases what I want is not the number, it's the _meaning_ of the number. Be it the Command ID, ram block Address or whatever it is. Generally, having code sprinkled with magic numbers is pretty shitty.

In my view:

      a = a<<18;
      a |= b<<8;
      a |= c;

is a kosher use of numbers. But

      case(ChoiceID):
        switch 1:
          /* Do somethin'*/
        break;
        switch 26:
          /* Do somethin' else*/
        break;
        default:
        break;

is not. Generally, numbers are ok as long as you express mathematical ideas nut not ok when you express logical ideas.

<comment><USER4> Heh, you disagree, then go on to agree. You even provide an example! Another good one is computing the Hamming weight, where the code is far more understandable if you have the numbers right there.

Even your "switch 26" isn't always bad. If the value only occurs in exactly that one place in your code, it's probably better to use a comment in plain English. A comment is more readable than DO_SOMETHIN_ELSE and, normally, would go right in the place where you actually use the value.

</comment></comment></comment></comment></comment><comment><USER4> Don't overlook the fact that lots of bug-finding tools support plain old C best. Yes yes, it needs them more, but... at least the tools exist!

Get all the tools. There are free tools like "sparse", a tool Linus wrote for his kernel. There are expensive tools like Coverity. Get them all. Use them all.

Build your code with all the warnings enabled. Use multiple compilers, even if they don't compile for your target.

</comment><comment><USER5> [https://en.wikipedia.org/wiki/MISRA_C](https://en.wikipedia.org/wiki/MISRA_C)

</comment><comment><USER6> Ada is known for those kind of applications. Very restrictive types / contracts make it a good choice.

Of course a lot of safety critical stuff is still written in C or C++. They may not be perfect, but they're not terrible choices.

<comment><USER7> Ada has been used a great deal in the past for military applications, including flight control software for military planes. One of the real advantages of Ada is that there are a number of tools designed to make sure that Ada programs are about as safe as it is possible to make software.

I can't help wondering if some of the problems the F-35 is having is because its software development is being done mostly in C++ and C.

Unfortunately, I would be really surprised if there is an Ada toolchain that can produce code for a microcontroller like the ESP8266.

<comment><USER6> GNAT seems to have no problem with that: [https://github.com/RREE/esp8266-ada/wiki/Steps-for- building-...](https://github.com/RREE/esp8266-ada/wiki/Steps-for-building-on- Linux)

</comment></comment></comment><comment><USER8> Depends on the field. Aeronautics and reactor control seem to use "safer languages" like Ada quite a bit.

In factory automation I have only ever seen C, and AFAIK automotive is the same (they seem to be more open to C++, though).

Most of safety-critical development (as I know it -- again, no satelites or nuclear stuff) is documentation, testing and FMEAs. Quite a bit of "patterns" or procedures, as well, like memory testing in the background, redundant variables, cross checks between controllers, plausibility checks etc.

But very, very little focus on saner programming languages.

</comment><comment><USER9> Ada. I personally lean more and more toward functional languages these days, but despite that, I'm incredibly impressed with modern Ada. Particularly the Spark subset of Ada, which is perhaps the best-thought out, more coherent, most secure language around for general programming. It's the epitome of a well-engineered project, with excellent tooling, and formal verification options to boot. If I had to build something safety critical, I wouldn't hesitate to choose Ada.

And it looks like some folks have already been using Ada on the ESP8266, here are instructions: [https://github.com/RREE/esp8266-ada/wiki/Steps-for- building-...](https://github.com/RREE/esp8266-ada/wiki/Steps-for-building-on- Linux)

</comment><comment><USER10> The Power Of 10 is a good place to start.

[https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...](https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety- Critical_Code)

The summary would be:

Use vanilla C with some rules about things like memory, testing, and recursion. Testing and static analysis are your friends.

</comment><comment><USER11> +10 points for Ada. Great language. Barnes book is a great resources

</comment><comment><USER12> I work on industrial control and we typically just use C.

</comment><comment><USER13> This is a tangent, but Wikipedia says this about that chip:

        The ESP8266 is a low-cost Wi-Fi chip with full TCP/IP stack and microcontroller capability produced by Shanghai-based Chinese manufacturer, Espressif.

Am I alone in the concern that in a safety critical environment, the phrase "low cost" should be more of a concern than the choice of language?

<comment><AUTHOR> Totally not :) Just for reference, I'm not actually planning to build a safety-critical device with an ESP8266.

What piqued my curiosity was this project:

[http://openaps.org](http://openaps.org)

It's basically a homebrew controller implementation that uses data from a continuous blood glucose monitor to talk to an insulin pump. They're using Node and JavaScript from what I can tell from the GitHub. They're obviously conservative for safety concerns. The code runs on a Raspberry Pi 3.

This got me wondering - what language WOULD be used in 2016 to code something safety-critical? Is there anything coming from research that's better than C? My initial thoughts were something like Elixir, but really anything strongly type-checked and verifiable. Rust was another thought I had.

Looking at this my immediate thought was also "what's the tiniest micro that could do this job instead of the power-hungry Pi?".

I guess everything is C or assembler in the end anyway :) The impression I get from these responses is that a restricted subset of plain C seems to be the most practical solution today.

EDIT: I'm the OP if it isn't obvious, different account.

<comment><USER13> Thanks for the clarification.

I had a look around and I can only guess that the extensive hard limits that they document in their design fulfil the safety requirements on their own.

</comment></comment></comment><comment><USER14> If you want to go further, you might be interested by proving your software and formal method, something like the B-Method ; [https://en.wikipedia.org/wiki/B-Method](https://en.wikipedia.org/wiki/B-Method)

Unfortunately, I only know their name and never use it.

</comment><comment><USER15> Really out of my realm but maybe Rust?

<comment><USER6> Probably a nice choice in a few years, but at this point it's rather experimental on anything but main, supported platforms.

</comment></comment><comment><USER16> Just do what JPL does: [http://lars- lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf](http://lars- lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf)</comment>


Chinook Wawa, a pidgin language that combined Nootka, Chinook, French, English - <AUTHOR> http://www.bbc.com/travel/story/20181002-north-americas-nearly-forgotten-language <comment><USER2> What a strange thing to see on HN. I am from Wasq'u tribe, and one of the very few people on the planet who has a dictionary for Kiksht Awawat, the dialect of upper Chinook from which the Chinook Wawa borrows many words.

There are perhaps 3 fluent or mostly-fluent speakers left.

I am also one of the only descendants actively attempting to learn the language. I travel 5 hours down to the Warm Springs reservation Sunday to work remotely and learn the language, and commute back up on Wednesdays.

There are many anthropologically interesting things about learning the language:

\- Languages die like people. The speakers have forgotten useful things, like "brown".

\- The language is well-tuned for a way of life that has been more or less obliterated. It is a river language, and the idioms/vocabulary/etc. are geared towards fishing. But the Dalles dam destroyed the fishing ground. The language will never be what it was.

\- The Kiksht dictionary would be very useful to the speakers of Chinook Wawa on the Grande Ronde reservation, but because the tribes dispute land, the Confederated Tribes of Warm Springs won't give them the dictionary.

</comment><comment><USER3> Native languages magically disappeared because their native speakers, after 10,000+ years living in the same region, abruptly became very bad at living, and died.

There's also 50% chance that it was settler colonialism, ethnic cleansing and genocide.

<comment><USER4> Ok but this is a pidgin of a bunch of languages, including European, Native American, and even Asian ones. All this means is that all those groups were trying to talk to each other, which isn't a bad thing.

Chinook Wawa only became a thing < 300 years ago, and died out not because of genocide or colonialism, but probably because the prestige language of the area shifted to the point where it made most sense to just speak that language.

<comment><USER2> No, that's not correct.

As I said elsewhere in the thread, my family is Wasq'u, and we spoke Kiksht, a dialect of Upper Chinook that Chinook Wawa borrows from.

The boardings schools implemented on the reservations had the stated and explicit purpose of obliterating the culture, customs, and especially language, of the indigenous people.

If you hang out for any amount of time on the reservation, you know that people stopped teaching their kids the language because they were afraid of what would happen to them if they did not assimilate. The evidence is incontrovertible. There is no factual account that contradicts this.

I would know -- my grandmother was the first Native American woman with 2 PhDs, and her thesis was literally about this. I have been steeped in this history since I was a child.

</comment></comment></comment><comment><USER5> > It was used so extensively that it was the language of courts and newspapers > in the Pacific Northwest from about 1800 to 1905. This makes it sound like > all the newspapers were in Chinook Jargon. But the only such paper I've been > able to find was this > [https://en.wikipedia.org/wiki/Kamloops_Wawa](https://en.wikipedia.org/wiki/Kamloops_Wawa) > —first published in 1891 and doesn't seem to have had too wide of a > circulation.</comment>


Ruby Objects in the deep C underworld - <AUTHOR> https://www.omniref.com/ruby/2.2.0.preview1/symbols/Object#annotation=4032415&line=1

<comment><USER2> To anyone who loves this I highly recommend reading "Ruby under a microscope" by Pat Shaughnessy.

[http://patshaughnessy.net/ruby-under-a- microscope](http://patshaughnessy.net/ruby-under-a-microscope)</comment>


Top habits of the wealthiest people - <AUTHOR> http://financiallyfit.yahoo.com/finance/article-110926-6907-5-top-5-tips-to-build-wealth-and-success?ywaad=ad0035&nc

<comment><USER2> The problem with this article that it's not consistent with the people it references. Can you imagine Warren Buffet buying a house in the Hamptons? Plus these aren't even all of the "wealthiest" people - they're just wealthy people who happen to fit the point the article is trying to make.

</comment><comment><USER3> this will almost certainly get downvoted, but when i saw this title, i was reminded of a similarly titled list: <http://www.mcsweeneys.net/links/lists/23BrendonLloyd.html></comment>


Scaling Django for a Russian search engine - <AUTHOR> http://softwaremaniacs.org/blog/2008/02/24/why-offline-crashed-en/ <comment><USER2> Use of InnoDB and an MD5 primary key is problematic and not an isolated situation.

InnoDB works in 16KB pages with 13 bytes of transactional overhead per row and a default page occupancy ratio of 15/16. InnoDB attempts to store rows in primary key order.

Using a composite primary key of (host_id,session_id) would be preferable using an MD5 hash as your primary key for two reasons. Firstly, the composite primary key is smaller. I'm assuming that they used an ASCII representation of the MD5 hash. That would be a 32 byte primary key. Whereas, a composite primary key could six bytes or less.

Having a smaller key means that B-tree index fan-out is improved. Essentially, the database has to access less index blocks to find a row of data. This occurs partly because the overall size of the index is smaller. More importantly, smaller keys allow more pointers and therefore the index tree is broader. Smaller size allows an increased proportion of the index will be cached and the broader tree ensures less skipping through uncached blocks.

Secondly, the output of the hash is essentially random. This conflicts with InnoDB's preference to store rows in primary key order. It also creates a huge amount of cache churning as branches are added anywhere and everywhere in the index tree. Whereas, a composite primary key with an ascending component allows very good insertion and lookup rates with minimal cache or disk seek operations.

I suspect that the situation was compounded by use of InnoDB's autoextend. When pages are consumed and the InnoDB storage is grown, data is effectively appended rather than being stored in preferential order. Multiple autoextend operations can make performance degrade. However, given the description of a performance wall, it is likely that another known circumstance was also encountered.

<comment><USER3> _Secondly, the output of the hash is essentially random. This conflicts with InnoDB's preference to store rows in primary key order._

I don't know what kind of lock granularity InnoDB supports but if there are times when you actually want this behavior in order to reduce lock contention.</comment></comment>


Animated evolution of recurrent neural network state space - <AUTHOR> http://clevercode.blogspot.com/2010/03/animated-evolution-of-rnn-state-space.html

<comment><USER2> So let's see. Parity is kind of a large version of XOR right? Does a multilayer NN fail at this task or does the topology have to expand with the input dimension for that?</comment>


Post pc has nothing to do with windows - <AUTHOR> http://techcrunch.com/2011/09/02/post-pc-has-nothing-to-do-with-windows/

<comment><USER2> > there aren't any other tablets that are worth a damn

There's almost a smell of desperation in how determined the Apple centered blogosphere is to ignore or write off Android / Honeycomb right now.

I went to a workshop the other day, the score was three Transformers to one iPad; ASUS just upped their estimates recently to 800,000 per quarter. A colleague at work told me her husband was getting one. He just wanted something different from the iPad.

I'm not claiming they are anything like competition for the iPad yet in a market sense. They are a niche obsession, mainly among geeks. But the Galaxy Tab - thinner, lighter, better screen than the iPad? So good Apple is suing in panic to stop it before it even hits the shelves? "Not worth a damn"? Come on MG ...

</comment><comment><USER3> I love the form factor of my ipad, but realistically, it's nothing more than a media reader to me. With my bluetooth keyboard, it gets about 5-10% better.

But, for it to become my laptop replacement, it would need an entirely new operating system. Its current OS is just a toy, as far as I'm concerned.

Of course - I realize that 80% of the population aren't doing 'computing' - they're mainly viewing media with a few edits here and there.

<comment> cgrand-net iOS isn't that much a toy if you consider it as the OS of an inout/output device (aka a dumb terminal).

</comment></comment><comment><USER4> "I'm writing this on my laptop (a MacBook Air), but I really just want to be browsing the web on my iPad right now."

So... why aren't we blogging on our iPad? I call BS on this "post PC" thing. The iPad is not the right tool for _every_ job.

</comment><comment><USER5> Maybe for Joe Bloggs who uses their "computer toaster" for the usual purposes: Facebook, email, twitter, music, movies, pr0n and being a good little consumer.

However, those of us who really NEED to do work on a machine, it'll never cut it and neither will the cloud.

If it goes closed everywhere, I'm out.</comment>


Facebook blocked our url and there's nothing we can do? - <AUTHOR>

Site is completely harmless.. I don't get it?<p>URL: http://www.freesociety.com <comment><USER2> Looks like a Weebly issue, see [https://www.facebook.com/weebly/posts/132902413424071?commen...](https://www.facebook.com/weebly/posts/132902413424071?comment_id=725181160862857&offset=0&total_comments=34) (last comment)

<comment><USER3> Hi,

I help run the anti-spam team here at Weebly, and I can report that we're not observing any notifications from Facebook indicating that sites on the Weebly network are blocked. I've run a few tests using some popular sites on the network, and wasn't blocked from posting any of them.

More importantly, the site that the OP posted is not hosted on Weebly.

I recommend reaching out to Facebook for more information.</comment></comment>


SensioLabs successfully closes its $7 million Series A financing - <AUTHOR> https://sensiolabs.com/en/a_propos/communique_de_presse_funds.html

<comment><USER2> I do not know how good it will be for the PHP/Symfony eco-system but that's great news for them, as long as they keep their strong open-source engagement.

They are now a real open-source editor company, way more "pro" than "an agency building a framework" and that's good for everyone.</comment>


Delivering a consistent Twitter experience - <AUTHOR> https://dev.twitter.com/blog/delivering-consistent-twitter-experience

<comment><USER2> The coming tighter rules on client apps are worrying. The "things that make twitter twitter" are not geegaws. It's time for someone to blow the dust off identi.ca

<comment><USER3> Yes, this worries me: "in the coming weeks, we will be introducing stricter guidelines around how the Twitter API is used".

It's the start of them inserting points of control in their system to allow them to deliver inline advertising that clients apps can't strip out.

</comment></comment><comment><USER4> A big part of what makes Twitter wonderful is that it's home to the "cool kids" right now. If Twitter starts restricting third-party clients like Tweetbot, or making ads harder to avoid, it may generate more money for Twitter, but it'll scare away some of the great conversation.

I don't know if it's feasible, but I wish that services like Twitter would let me pay a subscription to not see ads, promoted tweets, and other services that "enhance" my "brand experience".

</comment><comment><USER5> From Sippey's post:

 _You need to be able to see expanded Tweets and other features that make Twitter more engaging and easier to use. These are the features that bring people closer to the things they care about. These are the features that make Twitter Twitter. We're looking forward to working with you to make Twitter even better._

We really don't need to be able to see these features - it's you who needs us to see them. These are not features that bring us closer to things we care about, these are features that enable you to sell us to brands.</comment>


I have lost interest in what I love: tech. I don't care. Am I burnt out? - <AUTHOR> Hi
I've recently got to a point in my career where I'm fed up with it. I find myself literally not caring aside from the occasional moment where I have a conversation/debate or something spikes my interest but even that normally expires quickly and I don't want to finish that thing of.
I'm tired of daily issues at work. I'm tired of hearing the same things and as a result I'm grumpy, not happy and even unwilling to help others. I'm also tired of it. I feel tired and mentally drained.
I used to be interested and motivated in doing home projects, home lab etc and writing some code. But I can't even be bothered with that any more.
I wanted to ask HN for advice and to see if anyone else is experiencing this.
It's effecting my productivity because I literally can't bring myself todo any work, the thought of it just bores me and I've literally no interest. whatsoever.
I've got some savings and have decided to quit work for a couple months to see if that helps and maybe try and rekindle my interest in IT and maybe do some small projects at home. I'm not a developer but I can write enough code to get me by.
Thoughts? <comment><USER2> Are you me? I'm in the same boat but without the savings and the sole breadwinner for my family.

My dream is to build some sort of SaaS product that pays the bills and spend time outside of working on that to work on other projects that I could monetize. Unfortunately, the burnout makes this less interesting to me.

I think some time off might do you some good. I don't know what your background is, but maybe re-focusing your career might help? I've been considering a move to more of a DevOps type of thing since I like to code and I'm comfortable with infrastructure. The problem there is that there's so much to learn and the burnout kills my enthusiasm.

<comment><AUTHOR> It sounds like we're in a similar situation. My background is actually infrastructure but I've been doing DevOps for the last 5 Years or so. I write a lot of PHP and Ruby and I think enough to write a small SaaS product with the help of frameworks etc. I can write to a decent level but not the same level as a full time developer.

The chances are I'll take some time off and do nothing. I'm just hoping that after a week or two of being off I'll get some sort of spark to write some code and bring one of my projects alive. I would like to monetize them but for now I would just be happy to complete one of them! Whatever the case I'm keen to ensure I don't do nothing whilst having time off!</comment></comment>


Posthaven Launches In Public Beta - <AUTHOR> http://techcrunch.com/2013/03/22/posthaven-launches-in-public-beta-has-saved-850k-posts-since-posterous-announced-its-shutdown-date-of-april-30th/

<comment><USER2> I signed up for an account today. They don't give much away on their homepage, so here's a preview of the current post editor for those interested:

<http://d.pr/i/189H>

You can sign up today for $5 and you won't be billed again until they're out of beta. I felt it was worth doing because I support their vision and I'm keen to see how it develops, even though the actual product is very bare bones at the moment. (e.g. No template editing, no pages, can't save posts as drafts.)

What they have so far seems fast, clean, and easy to use, though. The environment is refreshing compared to WordPress and more suited to medium-to- longform writing than tumblr.

My advice to the creators: show actual mockups of what you're hoping to build. (e.g. <http://john.onolan.org/ghost/> )

Promising never to sell out is great, but I would much rather see a visual pledge in the form of, "This is what we plan to make [screenshots] and this is the order we're building those features." Even if you don't offer a definitive schedule, at least your beta backers will feel more invested in the journey you're on.

<comment><AUTHOR> Thanks for this feedback and for your support. I really appreciate it. I'll try to incorporate all of this into the site today.

</comment></comment><comment><USER3> Hey, someone explain to me what happened here... seems like twitter bought Posterous to shut it down, and the founders took the money and basically started the same product with a new name and a pay model.

<comment><AUTHOR> I left Posterous over a year before the acquisition due to a difference in opinion over strategy. Brett had also left before. I didn't agree with where my cofounder wanted to go with it. I was bummed to see it didn't work out as we had hoped when it was acq-hired. I use Posterous a ton, and I needed a replacement anyway. Thus, Posthaven. I've been working at YC since 2011, actually.

<comment><USER4> Last year, I started using Posterous, both as blogger and developer.

As a blogger it worked fine.

As a developer it was terribly supported. The API was fine, but the implementations were often terribly flawed. Tags could not be deleted. Posts entered with markup could not be retrieved as markup. It was almost impossible to connect to an engineer at Posterous who cared.

I do hope Posthaven succeeds. I encourage you to have an API. I encourage you to treat your external developers with the respect Posterous was unable to show.

<comment><AUTHOR> Makes sense. We've been careful to stick to RESTful endpoints so it should be a matter of creating API keys and documenting it properly.

<comment><USER4> The Posterous API was very RESTful and was my first real exploration into that. I wrote an emacs posterous blogging extension, and it was a very valuable learning experience in REST.

</comment></comment></comment></comment></comment><comment><USER5> Advice to startups: list your price at its yearly rate, not monthly. I see the words "per month" and I think yet another thing sipping on my bank account every month. It's silly but it's easier to accept that I'm dishing out money for something that I won't have to think about again until a year.

<comment><USER6> I think you're in the minority, there. People notice the numbers first, and the lower the number the better.

<comment><USER5> You're probably right.

</comment></comment></comment><comment><USER7> Hi Garry (& Posthaven team),

So I've used Livejournal, Dreamwidth, Tumblr, and Posterous before, maybe a few other blogging services. LJ has disintegrated due to $xyz politics, Dreamwidth is pretty awesome but very small, Tumblr is looking for $$$, and Posterous is, well, you know.

So I regret to say that I do not look forward to using Posthaven. I instead plan to write my own content system that is git & markdown driven that renders out to my own site, paid for by me. You see, I do not trust content hosting anymore without significant reason to believe they won't drop me into a hole because $business-reason. Perhaps if Posthaven is still a going concern in 5 years and fully self-owned/IPO'd, then I will consider it a reasonable place to put time into. I guess I've just gotten burnt and my crispyness is starting to show.

I do wish you the best of luck, and I hope that Posthaven is a long-term stable business.

Regards, Paul

</comment><comment><USER8> I love the concept of Posthaven because it says that a huge exit doesn't have to be the end game for every startup.

They've made a promise to their users to live by a sustainable business model instead of shooting the moon. Writing should be permanent, but the model of startups is one that favors the temporary. This seems like a logical next step.

</comment><comment><USER9> I've decided that any content I produce in the future will be completely under my control, and in this context I've been very pleased with the Octopress/Jekyll setup I installed for the Rails Tutorial news feed (<http://news.railstutorial.org/>) once the Posterous shutdown date was announced. That said, I'm really happy that Garry and Brett have made Posthaven, and I'm excited to see them come so far so fast.

</comment><comment><USER10> Anyone who complains about how they can't trust the Posthaven team because Posterous was shut down has to put $10 into the 'poor reading comprehension' pool.

</comment><comment><USER11> Is there an option for a paying customer to "suspend" his account? If so, then how long after "suspending" would the customer's content get deleted?

<comment><AUTHOR> We were thinking if someone pays for a year, we'll just keep the content online forever. Paul Buchheit actually gave us that idea.

<comment><USER11> I like this idea! But what happens if someone "suspends" their account after 1 month? How long will the content remain online then?

There is no point in asking these questions about a free product. But since this is a paid product, an exhaustive Data Retention Policy will be very helpful, IMO.

</comment></comment></comment><comment><USER12> Just signed up. My thoughts: Looks pretty slick. My hat's off to you guys. I like that you already have custom domains option available, some services charge extra for that (i.e. Wordpress).

I realize you're still in beta, but I'd like to make a feature request: the ability to email posts to my blog and have them autoposted.

</comment><comment><USER13> I moved my blogs over the Posthaven and I have to say the import worked quite nicely.

Still waiting on custom styling before switching the domains over though. Hope that happens before April 30th. Also hope they do a better job of Markdown than Posterous.

</comment><comment><USER14> This is really weird.

> Its creators are also inspired by Google Reader's recent demise

What does a demise of a Google product has to do with another totally different product by a different company?

<comment><AUTHOR> Google Reader is a social service that was free. Google is a company that makes a lot of money, just not on that thing. The product was added to a "projects to cut" list in an email by a Google executive, and the next day it was axed.

Twitter bought Posterous for the talented team. A year later, the service is axed.

This is why things like Newsblur or Posthaven should exist for certain types of socially valuable purposes -- it's a paid service that won't go away. Because, well, money.

<comment><USER14> Your argument notwithstanding but there is no proof, or solid precedence, of a paid service surviving just because it is a paid service.

Google did not say (at least not publicly) that they're cutting GR because the service wasn't generating revenue.

</comment></comment></comment><comment><USER15> I think there should also be a free version, perhaps with restrictions.

<comment><USER16> Disagree. This is something you should have to pay for, especially given their promise to keep your stuff online forever. Paying makes the business model clear; a free plan starts to muddy the waters and certainly is no benefit to paying users or the company.

There are plenty of places to post for free if you don't care about keeping your stuff around forever. You get what you pay for after all.

<comment><USER15> So, one of the restrictions could be that my stuff would only be online if there is activity on it, subject to a maximum of say, a year.

I would like to try Posthaven and only if I feel that its worth 5$/month to me, then I can consider upgrading from the free plan to the paid one.

A free plan is beneficial to the company, since it would help in popularizing the app.

<comment><USER16> I see how having a free demo account might be helpful for trying out the service, but a permanently free account is totally contrary to the idea of posthaven.

Really though, paying $5 to try it out isn't a huge deal if you don't like the service -- you can cancel whenever. I'd rather see development of useful features than the devs worrying about a free demo thing. Because of the way it's structured, a free trial doesn't benefit the company or paying users -- growth is not the goal, sustainability is.

Bottom line: I don't think this is the right place for people unwilling to put $5 toward an awesome idea/business model. You can go use tumblr or blogger or whatever.

</comment></comment></comment></comment><comment><USER17> Awesome Garry!</comment>


Define Protocol Buffers messages with Haskell Generics - <AUTHOR> http://breaks.for.alienz.org/blog/2013/02/28/generics-and-protocol-buffers-the-hackage-years/

<comment><AUTHOR> Something I've been toying with a for a while now is finally/actually becoming useable for production code.</comment>