Vieira's comments

I was also considering buying "Domain Modeling Made Functional" but I read that it uses F#. Are you working with F# or do you think it will be easy translatable to any functional language?

Ask your parents or non-geek friends: Given the task of finding the files with the name ending with .txt which of the following two commands would you choose?

  find -name "*.txt"

  dir *.txt /s

Dropbox switch to Go? Where did you read that? If anything they seem to be "investing" in the Python ecosystem[1].

[1] https://tech.dropbox.com/2014/04/introducing-pyston-an-upcom...

This looks a nice way to experiment with CoreOS as it is not supported by DO or Linode but an AMI is available.

From what I understand they want to persist the trained model in a language independent way, so you can train the models with whatever language or framework you wish and then save it to a format that can be used by any other language or framework to classify unseen instances.

It is working in Chrome Beta for Android (v36)

I do not consider myself an hater (I have used both php and go). I would say the results on that page are consequence of php having more mature database drivers (written in C) than go, that is still in its infancy. If you look at for e.g. Plaintext it is more in line with what one would expect from a compiled language versus an interpreted one.

> It looks like the code viewing area was narrowed.

Doesn't look like it[1].

I'm not sure that a much wider github would be of use to me. Most projects usually place some kind of limitation on the number of characters per line and even in the file browser I don't find filenames long enough to take that kind of space. Maybe you have some other use cases worth sharing?

[1] https://f.cloud.github.com/assets/1354/660780/2e217312-d715-...

Support is quick to reply but often there is nothing they can do. I've tried contacting regarding both technical problems and billing issues and in both occasions they couldn't do nothing to help.

You are completely right on both. I'm sorry, my mistake. Regarding the Send button, or lack of thereof, it is much better blue than gray but, as you said, it is not as intuitive as a button. There is a lack of perceived affordance. It's one of the top 10 mistakes in application design that Nielsen[1] points. Of course Nielsen can be wrong and Apple can be right.

[1] http://www.nngroup.com/articles/top-10-application-design-mi...

That kind of thinking adds very few to the discussion. I respect Apple and I know they are a reference in terms of UI/UX. This does not mean however that they are immune to making mistakes. Your argument is, from what I understood, that as they are very good they must have thought of it and if they choose to do it anyway then it must be the best way. I do not agree.

Even for the message at the bottom of the screen there was more contrast before when the text was black. In a room it does not matter much but out, in the sun, you can tell the difference. Anyway, even if you read the most recent message most often than others (which is probably true) you often need to read the previous ones for context if the reply arrives some minutes or hours later. If you are out, previously you could read the last two or three messages without problems. No you have to scroll so that the previous message is under focus to be able to read. And what is there to be gained? Isn't the fact that older messages appear before the new ones not enough to hint about their order?

Again you raise the argument that Apple always knows best and therefore it's laughable that I point out such a thing. Of course Apple would never make such a mistake. Just look at both photos and ask yourself which one can you read best. Also look at screen of the (beautiful) weather app and see if you can check your signal or even the time[1].

Also do you think that yellow text on a light background is a good idea in terms of readability? Because that's the color of the "actionable" elements in the Notes app.

[1] http://tctechcrunch2011.files.wordpress.com/2013/06/ios7-app...

> I don't care about flatness or skeutransmogrification or whatnot, but the damn thing must WORK.

Absolutely. I don't understand how so many people are focusing on the highs and lows of the UI but are ignoring serious UX problems like the one you pointed.

Apple says "Nothing we’ve ever created has been designed just to look beautiful. That’s approaching the opportunity from the wrong end." but then they change the perfectly readable Messages screen to a less readable one that has the only advantage of arguably looking better. And it's not the only problem IMHO.

On that screen used to be a send button that invited interaction. You look there and you know that it's "actionable". Now in the new version there is no button, only a gray text with "No Perceived Affordance" that looks more like a description than an "actionable" element. The most important "action" on that screen happens when you press a gray text on a gray background!

And the call screen? On the iOS6 one it was easier to read the name of the person who is calling because the white text is above a black overlay giving it enough contrast. On the new one the text although bigger is lighter (as in less bold) and is directly on the image. Light backgrounds (sky, clouds, etc) will make the text barely visible. Also how can I reject a call? There is nothing on that screen supporting the second most important functionality that is expected from it. Even accepting the call is now more complicated. The size and position of the elements makes more sense now but the text is lighter (less readable) and it's now more complicated to accept a call: before you only needed to touch accept, now you need to slide.

The home screen: even ignoring the aesthetics that I personally don't like, it's undeniable that the text is much more readable with iOS6. The small border and shadow made it readable with virtually any background. Also the icons were easier on the eyes, the new bright colors tire/irritate the eyes more. Also the relationship between icons and the functionality they represent was already hard in some cases. For instance for someone that didn't know Safari it was not easy to tell which was the browser and which was the compass from just the icons. Also the photos icon was not obvious at all and the Music vs iTunes Store icons are almost the same with different backgrounds but now it got worse: none of the exisiting problems got any better and at least reminders, settings and game center got worse.

Of course there are a lot of screens that got better imho. Music, contact view, the calendar, clocks, compass, weather...

I think the iOS team is facing a tough (and interesting) problem. They need to keep the edge they have in terms of app quantity and specially quality, so introducing big changes that break or degrade how apps look or behave and require big changes by developers can jeopardize their advantage.

On the other hand change in unavoidable. They cannot stop in time. Each iOS version that gets released with minimal changes is another catch up that will need to take place in a later version. The more changes are delayed the bigger they get. Android and even Windows Phone are moving forward and so needs Apple.

I think that there can be a certain feeling inside Apple that is not exactly change aversion but maybe is something close. They got iPhone so right and had so much success with it that maybe there is some fear that introducing significant changes can mess things up...

It also works for some commands even if you never run them before. For instance curl --i<nsecure> (and I never ran curl --insecure). Also pressing tab will display all curl flags starting with i and a one line description from the man page. Pretty neat.

I'm not sure if this is the problem but maybe running fish_update_completions is worth a try.

I think he was referring to DigitalOcean, not Linode.

I was only comparing what each advertises.

You don't know if the first one will perform better or not. It depends on the workload of each VM. If most of the VMs are idle most of the time, when one of them needs CPU the second setup may even perform better.

And I doubt that Linode runs more VMs per host than DO. Judging by the pricing is probably the other way around.

On Linode it is never hundreds. "On average, a Linode 512 host has 40 Linodes on it. A Linode 1024 host has on average 20. Linode 2048 host: 10 Linodes; Linode 4096 host: 5;"

On the other hand as far as I know DO don't tell how many VMs share a host.

It was a development box/env. Anyway it was not a problem with Arch. Same set of updates on Linode worked absolutely fine.