Recent submissions

Comment · 5 years ago
I used to have similar project called WhenEpisode.com. I was generating landing page for each show with the title "When is the next episode of...", it was catching some google traffic.
Comment · 8 years ago
At my company https://voicefox.com, our bot attends a meeting on Google Meet, GoToMeeting and others. We connect to them meeting using Linux-based Chrome and capture the recording server side. From our experience so far, Google Meet (new hangouts version) has the best quality of video
Comment · 9 years ago
That's a good comment and of course there is a list of approved stacks (not random list of languages) and we try to think about future. Hiring people wasn't our only reason and we had technical reasons to go with micro-services and multiple languages, but it was nice perk.
Comment · 9 years ago
That really depends on the startup, and sometimes starting with micro-services helps with hiring - In our case thanks to starting with micro-services we hired developers knowing different programming languages and they can work together on the project by exposing end-points/consumers. Of course I wouldn't recommend doing that for everyone but in our use-case we had to start with distributed system anyway due to quite complicated domain.
Comment · 9 years ago
Not anymore.

Just google everything when I need to find something. In the past I was using bookmarks to track blogs I follow but these days there is too much content. I just google/HN search stuff when I need to find something. I tried going back to bookmarking stuff/save for later but I just never got time to go back to the them.

Comment · 9 years ago
I ma co-founder of London based startup and salary was one of the reasons I decided to build dev team in Poland. East Europe is great resource for smart software engineers asking for 50% of what we would have to pay in London (and London is still 50% behind SF). I am surprised why so little startups are looking for remote employees.
Comment · 9 years ago
There are many business reasons to use micro-services not only technical ones. In our org we could hire developers fast as we can use multiple programming languages (we have few approved stacks, as micro-services do not share code base).

It allows us split out teams in to small agile units. That can e.g. deploy independently.

Getting new developers on-board take less time as they work on few small services and they do not need to be aware of the whole code base (at the begin)

Yes I agree there is technical overhead, and proper CI&CD servers are required, docker or e.g. vagrant is a must with micro-services. But including all the benefits I wouldn't say that we loses 2x more time than having monolithic architecture.

Comment · 9 years ago
I actually disagree, developers doesn't need to run the whole code on the local env. In my company we use development docker cluster where we keep instances of all of our micro-services and they are exposed (via vpn) to the outside world so you can call them by domains. When you work on the logic that e.g. would affect 2 micro-services you can just set-up 2 of them and make remote request to the dev env for everything else. I don't see any reason why you should run all of them on your computer.
Comment · 9 years ago
That's a good point, transactions are hard in the micro-service world. In my experience usually It's possible to re-design architecture to encapsulate transaction inside one micro-service. If you have transaction across multiple micro-service are they are really decoupled?

Similar problem is with doing asynchronous requests e.g. using RabbitMQ it is possible only with well designed boundaries as it's hard to control state of request if you do everything asynchronously.

Anyway micro-services is not perfect solution for everything, but even despite these problems I love working with them!

Comment · 9 years ago
Exactly, every decision is approved by me at the moment and we keep list of approved stacks.

Also to be honest I am not that afraid if we keep our micro-services really MICRO the worst-case scenario would be rewrite single micro-service - still better than struggling to hire dev team by 3-4 months.

Comment · 9 years ago
Well we have a list of approved stacks and yes this may became a problem one day but we try to prepare for that.

One of the things we do on the top of using micro-services is using docker for everything (dev, build and run on production), it's easier to pick up a project if the whole environment is already setup inside docker image. Like I wrote in my first post, It's very hard to find e.g. 10 good engineers knowing python in a month time (and we are startup, can not pay twice more than everyone else). So far this whole strategy work out, but I am not deluded and I do not pretends that starting with micro-services is a good decision for everyone in every use-case.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton