Herbert2

For me, an emphasis on Go indicates that I won't have problems with cross compilation and that I'll have a static binary to run. I'm more inclined to give a tool a try when I don't have to deal with language sandboxes.

Thanks for the tip, does FluentMigrator require me to duplicate the table structure in it's DSL or does it have a way to pick up EF Core tables & detect changes?

Re encryption, I was looking for a way to do automatic TLS via https://letsencrypt.org/. Closest I could find was https://github.com/natemcmaster/LetsEncrypt which is archived.

Using it for two days now on OSX for a client so I don't have much experience with it. First impressions are ok, the documentation could be better and it's not very googleable as you get a lot of irrelevant hits from normal .NET, MS really should have more creativity when it comes to naming. Problems I've hit which I wouldn't expect to hit in a more mature framework:

* Running EF Core migrations against postgres on startup. I wasn't able to google a solution to this. I hacked around this by deploying an init container with a migrate.sql script but I expect that'll bring me problems later on.

* Let's Encrypt. Found an archived package on GitHub, I expected more maturity.

* Not very easy to ascertain the state of the setup, things need to be registered in a certain order for them to work (UseDefaultFiles & UseStaticFiles f.i.). This would be made easier by me having more experience with the stack or better docs, still a waste of time.

General answer since this is a general question.

DB engine: Postgres, something more exotic (dgraph, cassandra etc) depending on use case.

API layer: Microservices with grpc, write services in languages which are/will be good for each service's use case. Allows for a relatively easy longterm upgrade path, service rewrites in new languages when staffing or needs require.

Frontend: React, because a) it's great and b) you will worst case be able to reuse a lot of techniques if you decide to use React Native, best case a lot of code. Structure the frontend with lerna and you can avoid the churn of JS build tooling for more stable parts of your application.

Caching: Redis or Memcache

PaaS: I like GCP more but they're pretty much the same dish plated by different chefs.

As a foreigner in Germany, I'd add to that list bureaucracy & the German language, a duet that does little to bolster the willingness of non-native speakers founding companies here.

react + grpc with services in go & python

Simplest solution I've found is to run the devserver in a gulp task instead of using any of the pipeline/compressor projects.

I'm all for less sprawl but artificial limits like the ones you're describe would IMO only needlessly accelerate gentrification. For instance, it's very difficult to get a spot at a daycare in Munich, not because there isn't space in the system but because the city can't afford to hire staff that can afford to live in Munich.

Very nice but very US centric.

capital controls.

It's understandable that developers aren't abandoning their current projects, but starting new ones suddenly carries the risk of developing for a platform that you have doubts that gamers will buy.

Alright, these were approximately the fields that were Postgre-fied.

CREATE TABLE event ( "references" text[], (was 2 tables, references and reference_on_event) "entities" text[], (ditto) "actors" text[], (ditto) "targets" text[], (ditto) "payload" json, (EAV) )

Gin index on all the text arrays. There are about 150k events saved per day and PostgreSQL is running on the same kinds of hardware as SQL Server was. The application is quite read heavy.

Anecdotal, I migrated a sluggish multi table SQL Server setup to a single table PostgreSQL by replacing the previous EAV setup with hstore and m2m "article-tag" tables with array fields. Exactly the same functionality, only 20x faster. Sometimes vendor lockin is worth it :)

I was hoping some of meteor's users could answer a few questions about it.

Can meteor use Postgres instead of MongoDB? Could meteor do sync with the database through a server-side rest client (instead of mongodb)? Is TDD possible? Is CoffeeScript possible?

I'm pretty sure that at Jane Street you get to solve engaging problems and get paid 250K+. OCaml or not, they're not going to have problems with hiring.

I seriously doubt OCaml's benefits over Python are so great that they overweigh not being able to hire someone proficient in it.

But people need to learn things like OO and memory anyway, why not do it with a language that teaches you both? It's not like the introduction to programming in Java would have final bufferbuffers everywhere to avoid garbage collection. C++, as bad as it is, teaches you both how memory works and how OO works.

I went through a similar switch from MSSQL to postgres. We moved 7 applications of various sizes over and the biggest hurdle was office politics. The migration never took more than a day for each app. ETL and reporting were not affected since we had previously integrated messaging (rabbitmq) pretty heavily into every system at the company and ETL gets their data from there.

We also switched the DB servers to over to linux and got a huge performance boost from that.

We did rewrite some stuff, but that was mostly to take advantage of postgres features like array types (instead of a article tags table, you'd have an tags array) which we used to speed up some applications. One we sped up by a factor of 10, just by using array types and offloading json generation to postgres: select array_to_json(array_agg(row_to_json(t))) from ( some query ) t

Self hosted sentry, very pleased with it.

Despite the overall ecosystem being rather small, the standard library and adjoining experimental packages are excellent. I wouldn't be surprised if go 1.2's stdlib would cover most of what Python's stdlib and Twisted can do.

I'd purposely avoid drawing any lessons from Iceland. We have the world's smallest independent currency and devaluation cut our purchasing power in half.

It could be, fast forward ten years and the majority of the smartest minds in the industry will have no experience with your flagship product.

I'd want to add that working in a windows for dev, linux for deploy environment will eventually make you constrain yourself to using libraries which work on both platforms.

I've found that CoffeeScript is great at standardizing the various styles of coding JavaScript that exist in an office.

I've mostly worked on the server side of things for the last few years but last year I decided to dip into mobile. I felt disappointed after trying MonoDevelop as I found a lot of the things I had really appreciated in server development missing or inadequate. Things like a proper package manager and easy integration with CI servers. I just got NuGet to work last month, after trying it infrequently over a couple of months. xbuild, I never got to work properly, sure I was able to run unit tests inside MonoDevelop but my expectations were a bit higher.

Meanwhile, over in Javaville, I can do just about anything Android related my heart desires with Maven and even CocoaPods in its infancy was a better experience than NuGet. Just my 2 cents.

Just wanted to say thanks to Ask for Celery. Absolutely fantastic for distributed systems.

The quality of this leaves a lot to be desired* and you would be better off with using a 1.4 project from somewhere like https://github.com/xenith/django-base-template.

*Hardcoded ubuntu user and hardcoded py26 and py26 paths in different files: https://github.com/prototypemagic/django-projectbuilder/blob... https://github.com/prototypemagic/django-projectbuilder/blob...

Same here. I recently upgraded a 2007 model for family member, added more RAM & a 120gb SSD. It runs faster than my 2011-pre-SSD-upgrade did. The new MBP is a fantastic machine today but I wonder whether it'll be as good in 2017 as that 2007 is now.

That kind of framework enthusiasm doesn't really stem from the closed minded mindset I was referring to. Most Ruby & Python devs I've met would admit that Java is a much better choice than their perspective languages for something like that requires distributed concurrency and speed (like Cassandra or Redis). The people I'm talking about are the ones that wouldn't look seriously at RabbitMQ because it's written in Erlang, not Java.

This is just my experience but if there has existed a common line of thinking with the rabid Java fans I've worked with, it would be closed mindedness to the point of being its own brand of Stockholm syndrome. The thinking that whatever the project at hand may be, a Java based solution is always the correct answer and there is nothing to learn from alternative platforms. I've heard "Why would anyone want to use anything other than Spring?" or "C# is shit" more than once. However, if you were to compare the experience of using Spring + Eclipse to C# + ASP.MVC + Visual Studio, you'd have to be pretty set in your ways not to admit that the latter is a much nicer platform to work with and that the Java eco-system shouldn't take something away from it. Having a standard web framework (ASP.MVC) makes .NET teams miles more efficient than the framework fragmentation that is Java web dev.

And if you're comparing it to Rails or Django, I honestly don't think you can easily find a 3 or 4 engineer Spring team that could deliver a product as good (or scalable) as Instragram in the 2 years it took them to do it in Django. You just can't iterate as fast.