Live data from Hacker News

“It's The Future”

circleci.com

511–520 of 536 posts

Re: “It's The Future”

#511
post #259

Earlier quoted context omitted.

Yes, but there's another dimension here. If another team breaks your build in a monolithic repo, you may or may not be able to resolve this quickly. You're in a contract with them about the state of the repo and thus your service. With microservices, the production version of their service would conceivably be stable. It moves the contract from the repo to the state of production services.

> If another team breaks your build in a monolithic repo, you may or may not be able to resolve this quickly. With a monolithic repo done right, the other teams broke their build of their branch, and it's up to them to resolve it. You, meanwhile, are perfectly happy working on your branch. When their changes are mergeable into trunk, then they may merge them, not before — and likewise for you. With multiple repos, th…

> With a monolithic repo done right.

Yes, that's the contract that you need to have with other teams. And it's the contract that is automatically enforced with microservices.

Re: “It's The Future”

#512
post #509
post #490

Earlier quoted context omitted.

Everything in a computer can be interpreted as a stream of bytes. For most things an object is a better interpretation.

You could then also criticize for example HTTP or even TCP for making you turn everything into "bytes". Shell doesn't enforce any particular interpretation of data. Pipelines simply connect one program's output to another's input. Interpretation is up to the programs.

>You could then also criticize for example HTTP or even TCP for making you turn everything into "bytes".

If these were the only standard protocols that existed, and people were trying to tell me this was great because it's easy to compose different network applications, that criticism would be completely valid.

>Interpretation is up to the programs.

But because there are no standards beyond "stream of bytes", the chance that two independently written programs working with non-stream-like data can communicate directly is extremely low.

Re: “It's The Future”

#513

Earlier quoted context omitted.

Having to work with people who see caution and wisdom as "getting old".

Virtues are generally disregarded by those who seek instant gratification. Most of the times that I bring up the concept of virtue to my peers in age they seem either confused with the concept or contemptuous of it. They behave like virtue is a purely religious thing, yet caution in the face of possible danger is a very basic survival skill.

How does the concept of morality have anything to do with enthusiasm for new technology?

Re: “It's The Future”

#514
post #501

Earlier quoted context omitted.

If it's free software it won't just disappear. If it's proprietary and hosted by an org that isn't making real money from it, that's a different story....

Is the development open though (serious question, I don't know how they do it with go)? Look at android, it's a closed project that the occasionally release some source code for. If google decided to drop android then it's a critical blow because there isn't much of a community around it.

It depends what you mean by "open." Anyone can subscribe to the go-codereview mailing list. Anyone can submit a patch, but you need to a) use gerrit and b) sign a (digital) contribitors license agreement with Google.

It's "open", but it would almost certainly collapse entirely if Google decided to drop support for it. (There's no sign that they'll do that, but it's not a risk you take with a language like C.)

Re: “It's The Future”

#515
post #509

Earlier quoted context omitted.

You could then also criticize for example HTTP or even TCP for making you turn everything into "bytes". Shell doesn't enforce any particular interpretation of data. Pipelines simply connect one program's output to another's input. Interpretation is up to the programs.

>You could then also criticize for example HTTP or even TCP for making you turn everything into "bytes". If these were the only standard protocols that existed, and people were trying to tell me this was great because it's easy to compose different network applications, that criticism would be completely valid. >Interpretation is up to the programs. But because there are no standards beyond "stream of bytes", the cha…

Lots of programs can communicate with JSON, XML, standard formats like that. If some legacy program outputs a non-standardized kind of output, that's a problem to be solved, not an inherent failure of shell scripting. There is no overarching successful solution to the problem of different programs using different data representations, but I don't blame this on shell; I work happily with shell scripts as do many many others. The same problem shows up the minute you want to use a Ruby module from Python, and rewriting everything in every language is not an economically viable solution.

Re: “It's The Future”

#517
post #515

Earlier quoted context omitted.

>You could then also criticize for example HTTP or even TCP for making you turn everything into "bytes". If these were the only standard protocols that existed, and people were trying to tell me this was great because it's easy to compose different network applications, that criticism would be completely valid. >Interpretation is up to the programs. But because there are no standards beyond "stream of bytes", the cha…

Lots of programs can communicate with JSON, XML, standard formats like that. If some legacy program outputs a non-standardized kind of output, that's a problem to be solved, not an inherent failure of shell scripting. There is no overarching successful solution to the problem of different programs using different data representations, but I don't blame this on shell; I work happily with shell scripts as do many many…

> Lots of programs can communicate with JSON, XML, standard formats like that. If some legacy program outputs a non-standardized kind of output, that's a problem to be solved, not an inherent failure of shell scripting.

But the shell language itself is one of these legacy non-standardized formats. Arcane escaping rules, multiple incompatible implementations, surprising ways things get interpreted as code (e.g. the recent bash CGI bug),...

Re: “It's The Future”

#518

Earlier quoted context omitted.

Totally agreed. As a freelance, it's really scary to invest time into a full stack of technologies. I should start a discipline to pick tools and not look back before n years went by. Maybe n = 2 or 3 ? (right now, I'm Objective-C - not even Swift - for native iOS, Ember for client, Rails for API/back-office and Heroku for deployment)

Honest question: How's that tech stack working out for you? What if you want to dev an Android mobile app? Have you looked at React Native at all? Thanks.

I sort of gave up on Android development by now. My mindset is iOS first if I need an app. And then consider a good webapp (with Ember then) if I want to extend to all smartphone users. If I needed a native Android development, I would try to find a partner able to code it, I wouldn't do it myself.

Re: “It's The Future”

#519

Earlier quoted context omitted.

Honest question: How's that tech stack working out for you? What if you want to dev an Android mobile app? Have you looked at React Native at all? Thanks.

React native was not mature enough the last time I had to solve this problem. After writing and maintaining native clients in both Android and iOS for years, I decided to try something different. SPA app + Cordova + writing custom, native plugins for performance has worked out pretty well. Some things in the UI are not as fast as I would like, but develop/test/release cycle is so much faster (web, ios, android releas…

I also gave up on frameworks like Cordova because (1) who knows if they'll still be maintained in a couple of years, (2) how reactive/efficient can they be to offer access to new features from the native iOS and SDK apps. I feel like pretty much anything Cordova is really good at, you can do it with a webapp.

Re: “It's The Future”

#520

I've spun up a lot of kubernetes clusters to test it out. A few months ago I also tested out Flynn, Deis, Deis Workflow, Openstack, and a lot of other options. I still haven't found a simple bootstrap script that gets everything set up on AWS and lets me simply deploy my application. And it's true that storage still seems to be an unsolved problem with kubernetes. Heroku is great, and free for small services. On the…

Take a look at Convox for setting up AWS then getting out of the way. It's open source and free aside from the base AWS costs. Disclaimer: I work at Convox.

This looks REALLY good, thank you! I will definitely be trying this out.
Post reply on HN