In Germany you have quite high minimum wages. Unions and works committees are quite common. Labor protected laws are quite strict. Sure, not every job is fun, but living with low income is not as bad as in the US. So, are people better at their jobs? Nope. Do people work better just because you pay them better? Nope. Should people get paid better, especially those with shirty jobs? Yes - of course. But there’s no reason to believe this would improve quality of work.
Germany in my experience is a country of too many scammers. Right from the taxi driver to the entrepreneurs, it is about cheating the customer. The funny thing is that it is native Germans who do it. Of course not everyone is like it, and there are plenty of top-notch open source developers that call Germany home.
He didn't really. The SQL is right there, and this is important.
What I've experienced (unfortunately) across multiple projects is that people who understand databases will write SQL with a nice collection of helper and wrapper functions as needed, and the people that think that databases are mysterious black boxes will reach for ORM. I've seen the ORM-happy teams getting scared at the idea of a million (1,000,000!) rows in a table, and they always neglect to set up even basic indexes or to think through what their JOINs are really doing.
YMMV but that's the pattern I see again and again.
Well, the SQL is always somewhere. If you use an ORM library, even if you use ActiveRecord, you will find some SQL in it. In the end, it always translates to SQL.
In the blogpost, the writer created a User Python object ("O"). A corresponding (R) database row will be mapped (M) to the object. That's basically ORM. Not as heavy as the usual libraries that support relationships etc, but still, ORM.
Good ORMs provide the best of both worlds. Basic tasks such as loading a single object from the database by ID and then writing it back after changes are made shouldn't require you to write any SQL, because everyone already knows what that SQL looks like, just let the ORM do it for you. A query builder component that allows you to programmatically build queries of medium complexity is also essential. And for anything not covered in the previous two cases, it should be possible to just write raw SQL or something like it without the ORM fighting you for it.
My preferred ORM is Doctrine and it provides all of these features. It has its own variant of SQL called DQL that lets you effectively write complex select queries as raw SQL with a bunch of object-specific conveniences built in, and get back an array of objects.
And from my experience, forcing people who know nothing about databases to write SQL will not make them learn about databases, all you end up with is worse SQL and more injections.
Although the worse offenders by far are those which decide ORM = bad and bypass it at every opportunity.
So let's ban ORMs because newbies don't know the entire toolchain. Yes, that will definitely solve it.
Why stop there? Let's ban RDBMS. If you can't contemplate a binary file structure and index strategy perfectly tailored to your application's needs ahead of using an RDBMS, why should we deign to let you use an abstraction layer with clever query planning and algorithms?
It's all too easy to morally 'ban' people from technology and gatekeep it behind wishy-washy nonsense like "ORMs are bad for beginners."
sqlalchemy allows you to separate ORM from SQL and combine them when needed. the idea that 'ORM == you don't have to write SQL and/or you can't write SQL' is, please excuse my strong words here, wrong.
my biggest gripe with sqlalchemy is that sometimes I know what I need to write in SQL (have a working prototype usually) and have trouble mapping the concept to sqlalchemy.core constructs, but that's mostly inexperience.
The active record pattern is an approach to accessing data in a database. A database table or view is wrapped into a class. Thus, an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database. When an object is updated, the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.
It was fashionable for a while to say it was an anti-pattern because that was a contrary view and ActiveRecord is very tied into building Rails applications.
It's not about fashion. Observations about fashion are no deeper than fashion itself.
It scales badly with table size, I think by design. That's why SQLAlchemy's and Hibernate's Data Mapper pattern is slightly more cumbersome to write, but works out much better.
It's a pattern where a single object (the "active record") not only represents a single database row, but also usually is responsible for saving/inserting data into the database (via save method) and retrieving them (via find methods). Because of this it breaks SRP. If this is neglectable or not, I don't want to argue here. Personally, I would not use it anymore because of bad experience in the past.
Active Record is NOT anti pattern. It's just one of ways to get things done related to (relational) database and your application. Active Record, Data Mapper, Raw SQL or whetever has its pros and cons.
I experienced similar with logging in into outlook.com and the teams app on Mac.
Accounts from different companies were mixed up. If I tried to login with my account from company A I got redirected to the login page of company B. It’s a real mess.
This has to be a joke.
If the Ruby implementation that saves the comment would simply contain the logic to save the static HTML file - the obvious implementation - no Postgres events are required.
Having a database separates the view from the model. If you want to modify the generated HTML, it's much easier with the comments being separate from the HTML itself.
I don’t say to get rid of the database. Of course it makes sense to store the comments there. I say get rid of 1) the database events and 2) the Ruby logic to listen to these events. This can be done by the Ruby saving logic. It’s just over engineering to use events.
In Germany it’s not unusual that you need about 3x the time by train instead if you go by car.
You can’t force those who have to commute to go by train.
You have to force employers to provide (maybe not only provide, but enforce) remote work options for all the jobs where it’s simply not necessary to be on-site.
For some people it is. I personally know people here in Berlin (or rather around Berlin, zone c) that in the past would drive instead of taking transit into the city a couple times per week because if you already have a car it’s cheaper than buying the Berlin A-C monthly ticket (the one that takes you all the way from the suburbs the city center). This is now no longer the case, and being able to use the same ticket elsewhere in Germany is a nice little perk.
Obviously it depends on where in Germany you are but in/around Berlin while driving is often faster it’s usually not such a big gap because you’d be stuck in traffic in a car but not on the train. It would often be more like ~50 minutes instead of 40 (but then you can read a book on the Regio/S-Bahn instead of focusing ok driving).
I‘m German. The truth is, people who right now use a car won‘t switch to public transport because of that ticket. There’s already studies about that for the 9€ ticket we previously had. So it probably won’t make a difference in co2 outcome. Also, those who benefit from that ticket, they usually still complain as they like to have back the 9€ ticket. So 49€ is still too expensive for them. Also, you need to keep in mind who is actually paying for that. This is the middle class. If you are part of the middle class in Germany chances are high that you pay more than 70% taxes & charges overall (payroll/income, trade tax, 19 % vat, electricity tax, health insurance, pension fund where it’s likely you’ll never see the money again… and so much more, I don’t even start writing about the Handelskammer).
So those who work have to pay a lot to keep the system running. And those who don’t, they get - compared to other countries - much help, but they still complain. There’s something in a human that makes him unhappy which money alone can’t fix.
I’m not against the 49 € ticket. I like the idea. The current government is even with all it flaws still much better than the previous one. But all those who just see the bright side of the ticket should think about the downsides, too.
> people who right now use a car won‘t switch to public transport because of that ticket.
Studies circulating in the media showed deviating results in this respect. For an opposing view: The Association of German Transport Companies (Verband Deutscher Verkehrsunternehmen, VDV) published results from one of their surveys in August, claiming that 10% of those that purchased the 9€ ticket did without at least one of their daily car journeys. 43% mentioned the avoidance of car journeys as one of their reasons for purchase.[1] Of course, this is only a sample of what is happening and is based on self-reporting by clients. But for a start, I think it is not so bad.
> claiming that 10% of those that purchased the 9€ ticket did without at least one of their daily car journeys. [...] But for a start, I think it is not so bad.
I don't know – I suppose you could say any car journey avoided is an improvement, but given the quite radical reduction of fares a figure of only 10 % avoided car journeys stills seems rather disappointing and to my mind rather confirms what was already known beforehand – while ticket prices should be reasonable and not outrageously expensive, the actual key to significantly reducing daily car usage (instead of mostly having people just make additional journeys using public transport) is by improving actual service quality and not by merely making tickets cheaper.
E.g. locally there was project where after a significant improvement in services (up to three departures per hour instead of only roughly hourly at best, plus direct connections into the city centre instead of having to change partway), 40 % of the passengers on that line were former car users!
That's what I'd call an actual success story, but unfortunately it seems that everybody has succumbed to some sort of "cheap, cheap, cheap" mania, and of course for politics slashing fares is an easier win instead of actually improving the infrastructure and somehow dealing with the evolving staff shortage [1] or the increasing planning bureaucracy [2].
[1] Not just drivers, even though that might be the most immediately visible to the general public – e.g. the local state government still doesn't seem to feel any sort of urgency in finally getting the now vacant chair of the railway department at my former university filled again, even though the former professor has been pensioned off already quite a few years ago and it's not as if we didn't also have a shortage of engineers for planning and construction, too.
[2] Instead of actual improvements, we only got a "Planning Speedup Law" ("Planungsbeschleunigungsgesetz") which in practice has hardly sped up anything at all, and sometimes possibly even made things worse (e.g. by having centralised the handling of planning enquiries at the Federal Railway Agency – but without actually correspondingly increasing staffing levels there). The only bright spot from the point of view of public transport in general and the railways in particular (though on the other hand it doesn't paint that good a picture for Germany as a whole) is that the transition of maintenance and planning of motorways from the states to the new federal "Autobahn GmbH" has been similarly botched up, and apparently the new Autobahn GmbH has quite rapidly managed to make itself rather unpopular, both as an employer for individual engineers, as well as as a contracting entity for the various individual construction and engineering companies that handle most of the actual serious work.
Our assessment of the situation is probably not too far apart. When I wrote: "But for a start, ..." I wanted to hint that there are a lot of other aspects that need improvement, too.
With regard to the "Planning Speedup Law" I am extremly sceptical too. I fear that in most cases this will result in the quality of planning suffering without an overall improvement in the situation. As soon as the stakeholders have adjusted to shorter planning processes, they will very likely submit projects at shorter notice and there will be complaints about too long process times again. At the same time, there will often not be enough time to examine the problematic points of the projects in sufficient detail and to look for better solutions.
My understanding is that this new ticker greatly simplifies a currently very complicated ticketing system.
But, I don't think that many people need a national ticket on a daily basis, and indeed people won't switch because of the very cheap price. Cars are vastly more expensive and people still prefer to drive.
There is a lot of politics involved, I think. Some think that public transport should be very cheap or even free (which of course actually means it's paid via general taxation) but really I don't think it makes a difference on behaviour because people can afford to pay even hundreds of euros a month if they have to.
Yes it’s making the ticket system much simpler. But I don’t think this was top priority.
For the 9€ ticket the rule seemed to be like „you can use it everywhere locally and additionally nationally for all trains which are not ICs or ICEs“ but in reality there were still some routes where you were not allowed to use it even though the train you use is an RE. Afaik you could not know except you were looking into the terms and agreements of the Deutsche Bahn.
There are two reasons why the ticket system was (and probably partially will still be) so complicated: first we have a lot of transportation companies. Each city/region has their own. And we have the Deutsche Bahn - which responsible for all the national tracks and trains. They all have their own ideas of pricing and they never appeared to be willing to work together. Also, you‘d need a good electronic system to cover all the data from all these companies to work with them but this requires some degree of digitalization which Germanys is not capable of. It’s a mess :(
If you are a decision maker, especially a CTO, you should be able to know who to give all the money.
True, there are too many people making the wrong technical decisions and by this increasing the complexity of a project easily by 10x or more.
But, to answer your question, if someone doesn’t know, (s)he’s actually simply not in the right position.
How would you name them then? In my experience many companies tend to give all the developers senior statuses even though they are actually still quite juniorish.
What’s wrong to be a Junior Developer?
I'd trim-off the "Junior" and leave it at that. For a formal job-title (as HR would demand) it's common to have Roman numerals appended, e.g. "SWE I" and "SWE II" before you get "Senior". The semantics is the same: "SWE I" == "Junior SWE" but without the
unpleasant connotations that the term "Junior" specifically has, especially when you have older folks coming in at an entry-level (e.g. from coding-camps or a midlife career change) where referring to a 40something as "Junior" just feels weird.
That's how it's done at all the US software companies I've worked at, including Microsoft and some startups.
My current company does has done away with job-titles entirely and we make up whatever we want on our business-cards (within reason).
Ok, seems like a good alternative. I didn’t know about it, in Germany it’s simply „Junior“ and „Senior“. If you are like a year or two in a company you usually are simply upgraded to „Senior“ no matter what.
Even though I wouldn’t consider Junior offensive I like the system you describe much more.
I‘m not sure if Laravel is a great benefit to the PHP ecosystem. It heavily relies on traits, magic active records (Eloquent) and global god-like objects with static methods („Factories“). For sure you can write clean, maintainable code in Laravel - but in my opinion it encourages to not do so.
I think Laravel is nice for quickly bootstrapping a project just to see if some idea works out. But it’s probably not a framework that proves how clean and enterprise-ready PHP nowadays is.
I think this is only a concern from a code purist point of view.
In real life business the productivity, security, ecosystem and guarantees of a battle proven tool matters *a lot*.
Not sure what alternative you're proposing here and I don't think this is the case, but I've seen already too many times the "Django/Laravel/Rails are bad so let's write our own awesome framework" and let's not get started on how that goes 99.99% of the times because you can already imagine it.
Also:
> For sure you can write clean, maintainable code in Laravel
This (and the opposite) applies to every single language and framework. In my experience it is more an attribute of the developer than of the tool/language/framework.
