elnygren

At least for OCaml/ReasonML it was "less than a week" for me and Haskell is probably not that much harder than another ML.

I get what you are saying and I also get what the author is saying it might be that you are missing something truly great in our engineering field.

However, it’s a better UX and less hassle to just bill customers in actual dollars/euros than in “MyCompany Credits” (that probably map 1:1 or 1:100 or 1:1000 to USD)

Most sane CI services also offer Postgres.

If WHOIS is how domain business works then there shouldn’t be a problem? It’s necessary for you to get the domain which would also be in your benefit if you’re buying a domain?

See: 6(1)(a) to 6(1)(f)

Correct me if I’m wrong :)

(it was deleted from everywhere else already because there was an event/request to do so)

It's a huge hassle compared to what many companies are doing with customer data now but I think it's for the best.

Most things about GDPR go like "Does it feel a bit shady? It probably is. Don't do that." (depending on your moral compass of course)

One thing is for sure: there's a lot of opportunities for consultants as all the big companies need help to resolve the mess of legacy systems storing customer data.

I never implied that anyone could do those things.

The point was that you’re not automatically participating in the “get lucky to become successful” lottery.

And a better personal ability would be to have supermodel genes :>

A business opportunity is not gonna magically appear if you are not constantly looking for one and you won’t be able to exploit it if you haven’t learned relevant skills and built a network.

To be honest, probably anyone can tell that the intro and first verse is a quite clear case of plagiarism. First 10-20 seconds is enough. It's the same melody, same chords and even a similar way of playing those chords with a guitar.

Something to do with marketing and how the two businesses differ (TVs B2C, monitors B2B)?

Or are there actual major differencies in the tech? Like what panel is used or something like that?

Probably a cool hobby project (and there’s nothing wrong with having hobbies!) but in it’s current state I don’t feel this to be too useful.

Just thinking aloud from my rear end: how about making a cross-platform framework with Swift? It already works well in the other major platform :)

Not too long ago it was the best.

What if I want/need Cassandra, ElasticSearch or MongoDB? An SQL DB is just one place where you have data and there are very valid reasons for using other solutions.

In fact, some people might argue that you want to do everything with event sourcing / kappa and use Kafka + specialised data stores.

GraphQL fits this universe perfectly. It also fits the one where you only use a single SQL DB since a GraphQL query translates quite nicely to SQL with minimal amount of code in between.

Load and bloat? Well that depends. If you're doing a realtime collaborative texteditor with a realtime chat, I just don't see how you'd get anything even remotely nice without what you call "load and bloat".

However, to return to the original topic. Which is simpler: a) creating a performant data API b) creating a performant server that handles data stuff just like a) AND all the rendering & UI stuff

Surely the latter is more complex since it has more responsibilities?

Average Joes want spinners, buttons, draggable stuff, toggles etc. that don't lead to a page load everytime you press them. Sure, you can say that "well just make a multipage app with some jquery". But at some point you're just approaching a SPA with SSR support.

Imagine facebook's chat but everytime you hit enter you had a full page reload :D

> In reality, multipage applications are faster than single-page ones.

I agree. They are faster for a single user when the usecase is a semi static page like a forum. However, the SPA + API model makes stuff easier for the backend side and allows that average Joe UI stuff. It scales well to millions of users.

The thing is, it's not about you. It's about everyone. We want to build services that please the majority and backends that stay up when the majority is logged in.

Also, it really isn't possible to build realtime/dynamic stuff with a "let's render some HTML on the server" mindset. How do you do realtime chat? Realtime games? How do you do a collaborative text editor? and so on.

JSON/SPA/AJAX are not there to so your static forum page loads fast. They are there because of the next generation of the web.

You could ask: why graphql instead of RESTful?

The idea of AJAX/SPA was to provide interactivity and a less technical UI that caters to the average Joe. AJAX/SPA moves some of the computation from the backend to the frontend so the service scales better for millions of users.

This forum is not going to be fast for millions of users (it might not even be for hundreds of simultaneous users) because the server has to render everything again for everyone.

Server side rendering is good for response times, that's why the SPA world went back to it (Google: react ssr). SPA is good for scalability and average Joe UI.

...and AJAX is there so we don't need to do a full page reload all the time. Again, not because of response times.

don't speak German? -> you'll receive bad service almost everywhere -> you won't get in to a lot of good clubs etc.

don't look like German? -> you'll get stares -> you'll be second rate / tourist / something

like drugs? like to party from 01AM to the afternoon of the next day? -> you'll love it

like sightseeing / going to the "best" places? -> everything's spread around a pretty big area -> you'll take the train / taxi / bus pretty often

like pretty buildings? -> in general, Berlin is ugly and crude. Except for the rich people areas and some places in downtown.

Partying two days without sleeping in the same club with a wide variety of substances is normal. There are weird sex club party thingies. There are ug techno parties with all kinds of debauchery. There are parks with more drug dealers than other people. Definitely not conservative, but somewhat xenophobic.

Or in other words: saying "thank you" in a language called cash.

The Django admin is meant for development. Ofc, it can be used by non-devs and I've seen a multimillion dollar business that mainly uses the builtin admin to manage their main product. However, there's always that point when customising something that is fundamentally different than what your needs are doesn't make sense.

The author is right about k8s. And what do you need to run stuff in k8s? Containers. And what is a pretty good container format? Oh yeah, Docker.

Although other containers exist, let’s be honest, people running k8s are almost always running Docker containers in them. And it all works amazingly well.

How do I run fat binaries in k8s? In a production ready and battle tested way please.

When you separate data from functionality into separate "things", composing things out of them becomes nicer.

I'm not a Haskell programmer, but AFAIK type classes contain functionality, NOT data (state).

Example of what I'm talking about: Clojure's Protocols.

  foo = foo || {}

It's just to not accidentally set a already defined foo as an empty object incase foo is already defined. Yeah... JavaScript...

Another common idiom:

  const PORT = process.env.PORT || 8080

1) Because almost no project is just CRUD Web UIs.

There are always so many small and big details that deviate from the CRUD Model. Unless you're building a Database UI. Which almost nobody wants as people want software that solves their real world problems - which rarely map 1:1 to a DB and it's schema.

IMHO frameworks that optimise the CRUD sacrifice a lot with regards to simplicity.

2) Plain CRUD Web UI is 90% automated, BUT: see item 1.

Rails and Django will handle almost everything hard for you and you just need to declare some trivial stuff like the model, url and presentation. The reason why you end up coding so much even in a Rails/Django project is because item 1.

Also, Rails and Django are definitely frameworks that sacrifice a lot in order to show off an easy basic CRUD setup. Both have ton of horrible OOP and metaprogramming under the hood and you'll have a tough time understanding what they do and how.

That being said, I've worked with both and I do like them, especially Django.