cmenge

This is hard to believe. I'm paying more than that for a household of 1. For 3 ppl, the typical comparison platforms quote EUR 900 p.a. as the cheapest option (3,500kWh estimate). At EUR 360,- a year, you'd get a mere 1000kWh which hardly supplies a fridge, lighting and cooking every now and then. The average price in Germany is close to 30ct per kWh, plus some kind of fixed base fee...

Not an expert, but this is also my understanding: The nerves are more like a neural network, not just wiring to the brain: https://heartbeat.fritz.ai/the-ancient-secrets-of-computer-v...

meh... - "Are car reviews watched proportional to car sales?" Seems Ferrari has really bad sales reps... - "Do food-related articles reflect what we eat?" My pasta-with-a-canned-sauce is still waiting to make it to the cover of Saveur.

My two favorites aren't on the list, perhaps because they were never put in these exact words or they are mis-attributed:

"Cryptography is not magic pixie dust that you can sprinkle on a system to make it secure" -Bruce Schneier [? - couldn't find a good source]

"If you think cryptography will solve your problem, either you don't understand cryptography, or you don't understand your problem." -Roger Needham / Peter G. Neumann

> It seems pedantic, but I think it shows that the lawmakers have an underlying misunderstanding of how tech (and the world) works.

In Germany, they actually demanded an "Internet eraser" (https://www.heise.de/newsticker/meldung/Digitaler-Radiergumm...) [so ridiculous I don't think anyone ever attempted to translate] so content, mostly images, would somehow 'automatically expire'. Never worked, images could be screenshotted, etc. etc. Said this was "highest standards made in Germany". Never made sense, never took off.

The US came up with Snapchat.

Agreed, but these rules are clearly defined, make sense to the common man and actually lead to what they should lead to, namely that I can, with great confidence, eat anywhere without being poisoned.

GDPR is terribly vague and creates a barrier-to-entry. Draconian measures may hurt large companies, but they threaten smaller ones.

EU is saying they don't like Silicon Valley behemoths' power but they want valley-like companies in the EU (sometimes even calling for a 'European Google', as if you could just pass a rule to make that happen). And then they create laws that make it easy for the large players and harder for their competition.

Everyone here spent a great deal of money for some compliance boo-hoo. FAANG has your consent and upgrades their policy, done.

To me, this seems like ineffective and incompetent lawmaking, no matter if the intentions were sound.

'Side-effect free' means that doing it once, twice or n >= 3 times (with same parameters) yields the same result, i.e. what it returns doesn't depend on any remote state that is altered by the call itself.

However, an idempotent HTTP call is certainly not a pure function which some people seem to be mixing up. Pure functions don't work with I/O.

REST is bit more specific and explicitly requires GET to be nullipotent which really means "effect free" - it just reads and doesn't alter the state on the remote system at all.

Side-effects like log files, rate-limiting, etc. will always exist, but they do belong to a different 'layer', so to speak. That is, these should be unobservable side-effects (also think about minuscule effects on the power grid, the fact that a request might write something to an ARP-cache, etc. - they all happen at different layers, so the quantum world state keeps changing, but that's not what this is about). Whether an X-Request-Count header violates the requirements or not depends on interpretation. From the garage door perspective, I wouldn't care...

Stereo set. I bought some HiFi equipment from the first money I ever made, 16 years ago. Still enjoy it every day, be it for music or movies... And the tech hardly ages, awesome.

I'm sorry, you're so right. I'm just one of the idiots on the Internet who haven't used a system for 10+ years (or the bulk of their existence at least) and makes condescending comments...

Being condescending isn't helping your argument here. No, I didn't think of SQL injection and I do have a vague understanding of the SQL grammar. The NoSQL injections seem a bit constructed and pretty much can't happen with a strongly typed language in the application layer.

...which brings us back to the original point: if you use tools you don't understand, chances are things go wrong.

Yes, but they don't match the data types your SQL database supports, do they? You're talking to a remote service here., i.e. varchar, decimal, datetime, etc. in SQL aren't the same as in whatever language you're using.

That's true for JSON as well, but you probably need JSON on the other side (the API) as well...

Well

1.) It's always a text-based interface. The ORM merely hides the fact. Type safety is weak, as is with JSON, but both aren't un-typed.

2) Yes, they are, and there are a lot of good use cases for relational databases. But if you have a number of services that share nothing (especially not the database), what is the foreign key good for?

3) You can do any style with any database. Overly aggressive normalization in read-heavy environments can be bad, as is de-normalization in write-heavy environments. Choose the tool for the job..

4) Why all over the code? Can't you make it easy to find the model classes? Doesn't seem so hard. Also, is this so different from, say, EF code first? And anyway, doesn't every SQL database in fact, have multiple schemas (the one in the db, the one in the scripts, the one in the ORM and the one in the code?) Is that really so different?

I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements.

But whatever DB you like, if you move the state of your application to another application (i.e, a database) you better make sure you really understand how it works.

For SQL databases, many people think they know how they work, but misconceptions seem widespread. Essentially, many beginners believe that SQL databases guarantee serializability everywhere and all the time, relying on the database (and OR-mappers) a lot / too much in my opinion.

Choosing a system that only offers very few guarantees forces you to think about them more explicitly. On the other hand, if you never bothered to understand SQL, you probably won't bother understanding anyDB's restrictions and guarantees either, and then everything goes to sh*t.

Some databases might be easier to understand than others, but I feel MongoDB is on the 'easier' end here. YMMV.

It's not about hype, it's about understanding how stuff works.

True, you often see people jump into a new technology without understanding the tradeoffs and the implications.

However, a lot of people don't have a deep understanding of the non-hype systems either. Seems to me everybody expects SQL dbs to guarantee serializable isolation every time and everywhere, for example.

Agreed. English might be a de-facto standard to some extent and many people use it if they have to. But the truth is, people are lazy and most people find it easy to communicate in their mother tongue and tedious to communicate in English.

Look at what happened to facebook when they started offering localized versions, their growth suddenly exploded over here.

I believe this will take a long time, and it certainly is a major barrier.

That argument baffled me as well. Using the 'dictionary size' defined by the distinct set of characters as an input for the entropy calculation seems absurd, unless the attacker has a way to know the dictionary, for instance because they know a login can be made using a numeric keypad alone.

Also, with that definition, a password 'abcde' would have much higher "entropy" than 'aabab', meaning that this measure penalizes actual randomness, where repetition and char-reuse are very likely.

I agree that it's far from what is needed in everyday tasks, but in defense of that process: if you are unable to implement fizzbuzz, Fibonacci numbers, etc., I am almost sure you can't understand react sagas or dependency injection properly. Mixed with more open-ended questions (why was React built? how does it compare to Angular? What's a generator function?), I believe this isn't the worst type of interview.

See the other side: a significant number of applicants can't implement fizzbuzz, Fibonacci sequences or anything, but ask for ridiculous salaries and their portfolios appear to be mostly borrowed plumes. We need a process that isn't too time-consuming to id the chaff, allowing for false negatives (people who are good at Fibonacci numbers and interview questions, but not much else), but keeping the false positives low (I explain the Fibonacci sequence first so it doesn't become a math riddle rather than a programming task).

Don't do plebiscites.

I read "lightsabers are totally possible". Where can I preorder?

So MySQL is great if you use none of its features, but then its really hardly different from all the other databases. So it's not the implementation, but the very promises that databases make which can't be held, but if you know that, you are just fine. Great insight, and pretty much the definition of NoSQL...

Fielmann Ventures | Hamburg, Germany | Onsite, Full Time, Visa, Relocation

We are the research & development department of Germany's largest spectacle retailer and design the future of the optical/retail industry. We evaluate technologies, develop retail concepts and build prototypes at a fast pace.

Positions

- Frontend Designer

- Frontend Developer

- Researcher Algebraic Geometry

- 3D Developer OpenGL and/or Direct3D

More information at http://www.fielmann-ventures.com/en/jobs/

Our hiring process: phone interview (screening) -> coding challenge -> phone interview (technical) -> interview (onsite)

For those suggesting the German UG, be aware that dissolving and operating it can be quite expensive. Fine if you have a solid business, problematic if it's more of a test and you simply needed some 'real' company for that stripe account...

Yearly filing must be done by a tax accountant and you have to pay for the 'services' of the Handelskammer, which is around 800 and 200 EUR at least, respectively, per year. Dissolving takes one year at the very least and incurs additional cost of at least EUR 500,- plus the year in which the company lives as a zombie, so 1.5k total.

maybe you should re-read the statement: "the barrier [..] people face is psychological: ... "

It wouldn't have saved Mitsubishi: https://en.wikipedia.org/wiki/Mitsubishi_Pajero

But I like the idea and will submit a few words

I find the behavior of the software manufacturer rude and unacceptable. CERN is certainly not the type of company that screws you over or produces counterfeit copies for their own profit; 30kCHF is an outrageous claim.

Sure, people using your software without a valid license is not cool. On the other hand, AllSIM didn't suffer any damages.

Also, there are probably not that many potential customers in the world for AllSIM(TM). Maybe CERN should have used their power to make clear that this was the act of a naive student, and that a ridiculous fine could seriously impede the future business relation with CERN...

Attaining a level of proficiency in "English" required for programming (keywors, mostly) is incredibly simple, if required at all. Just accept the fact that 'for' loops in some way. In mathematics, you will also have to learn what the uppercase sigma means, hell, they even use the greek alphabet!

It's not that programming skill (whatever that is) is bimodal, it's the effectiveness of the engineer in a typical development scenario. That stems at least partly from the fact that programming is hardly ever a one-person endeavor, contrary to running.

Since scaling a team increases friction and overhead, a small number of highly skilled engineers can be absurdly more effective than a set of teams, which also makes them more valuable, but not necessarily as extreme as in sports. Add preferential attachment to the equation (good engineers try to work with other good engineers / hire only top talent), and the U-curve starts to make sense IMHO.