vojant

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.

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

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.

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.

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.

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.

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.

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.

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!

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.

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.

One day I plan to share every detail of our journey, but at the moment we are too busy building our product. So far I am very happy with the decision to go with micro-service oriented architecture, but of course we had some issues with that - but hey there is no perfect solution!

Oh I didn't mention all the reason's why we use micro-services from the day one. We have very sophisticated use-case. We call-in to meetings using hangout, go2meeting etc to record them (we do speech recognition and many other thing with these recordings). In our case to concurrently call-in to many meetings and do processing in real-time it wasn't really premature optimisation.

I co-founded startup 6 months ago, since day 1 we use micro-services. For us the biggest benefit was that at the begin we could hire people knowing different programming languages (we managed to build a team of 5 in 3-4 weeks) and they could build a small parts of the system communicating via http/RabbitMQ. Downside is that we had to have a CI&CD from day one and it costs us some resources.

I am not saying microservices are cure for everything and of course there is a place for well maintained monoliths but I find that even for smaller teams micro-services can be just easier than monolith.

Run tests in parallel, only way too make it fast.

I broke my toe on the coffee table last year and in my old mbp battery swallowed - so it's not very comforting

Kinda like in No Man's Sky game.

I fully agree, Ubiquitous Language is the key part of DDD. As long developers and business people understand processes and speak the same language you can achieve DDD using any patterns/languages/technologies.

In DDD what I find the most challenging are changes and context: e.g. in typical sass application marketing team speaks about customer that comes from PCP, but from sales perspective customer is the only company setup through CRM system. Same word but often processes are completely different (post-pay, pre-pay etc).

Sadly, I never work in a team that implemented fully DDD - mostly because it was too hard to engage all departments to think about processes - technology behind that was the easy part.

That also means a lot of good stuff might not be legal as well. Like unofficial servers (even for games that are not longer officially supported), or mods?

I hope other countries won't follow this regulations.

MacBook Pro 13 (2012 - 8gb of ram, ssd) but I replaced OSX with Ubuntu.

Is there any option to search by price?

When I was a kid: Hackers (watched it around 30-40 times when I was a kid), War Games, Matrix, Sneakers pushed me into being developer, but the most impact on my current life had American Beauty as it made me thinking about working less. Another movie that I can think of is Social Network - It motivated me to on my side projects harder.

Thanks for sharing, this looks interesting.

Maybe you can use docker instead?

http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-d...

https://blog.jessfraz.com/post/docker-containers-on-the-desk...

>It's certainly not the key to getting a game on every device. I can't think of one browser game that people play on their devices. Even Words with Friends, the simplest 2D game you could think of, is not used from a browser - most people run the native app for that.

Because of performance, but streaming games solve this problem. Full screen browser wouldn't be any different than native game client.

I have never using OnLive, did they support playing via browser? Browser solution is key to this as almost every device support modern browsers capable of ruining OP solution.

Of course for some games it is a problem, but not for every game. Also I hope in the future latency problem will be solved e.g. but placing more DC around the world.

Yes I have seen this one, but it wasn't browser based. Somehow browser based solution looks much better.

Facebook wasn't new, Twitter wasn't new... Sometimes reusing existing components, and making them better is enough to do something great. It doesn't need to be always original work.

This is really cool, after watching this demo I wonder how the future of gaming might look like, e.g. we could pay subscription for a game and remote machine to run game on. This way even with cheap laptop we could play AAA games remotely. No more issues with hardware, drivers fps.