251–260 of 271 posts
Earlier quoted context omitted.
This is a good counter-argumnent to the frequent article decrying whiteboard tests.
Only if you assume it actually works, which is the most blatantly circular logic in this thread. This guy could have said "I feel like a daily prayer in the server room would filter bad devs" and it would be just as proven as his feeling about whiteboarding.
Earlier quoted context omitted.
Logic in the Database has the following issues: 1. it doesn't work well with source control 2. deployments, rollback, replication, synchornization - they don't work very well with db procedures 3. unless you connect directly to the db, then you must have some logic on the serverside, usually you end up replicating logic from the db to the serverside 4. Databases languages (even advanced ones like PL/SQL) are not expr…
4, 6 and 7 are my main problems with this. i occasionally have to work with a big application which is essentially written 100% in sql. you simply can't easily change parts without testing the whole thing from start to finish because automated testing at a granular level is horrible. and sql does not lend itself to encapsulation, it does everything to make it hard to break stuff down to manageable pieces and in sql e…
Earlier quoted context omitted.
Well, it depends. I've been in healthy situations where this was true. One company in particular where this was mostly true from the very top down. Of course, yes, there are plenty of situations where it is just double-talk.
The manager isn't a good politician if you don't believe his bullshit. If the manager himself is a founder, former programmer, or otherwise both intimately familiar with and committed to the process that actually produces the outcome, he may understand the importance of the work and really be working to ensure his team has what it needs so they can do a good job for the company. He's still working for the company, bu…
I've worked with a lot of really good managers who understand the role their group plays without having to delude themselves into thinking their team or function is primary. I think that's something that's really important regardless of the industry.
The most enjoyable jobs I've had have been those where there was good, self-aware management. While bad management is obviously a horrible time all-around, I've also had very bad experiences in the so called flat, self-managed models. For those to work, the greater majority of the team need to actually be self-aware, good (at least self) managers.
Earlier quoted context omitted.
As someone with a fantastic manager: it's great. He handles the planning and resource allocation for projects and makes sure that I have everything I need to be able to develop, this includes making sure that any external dependencies (like people not on our team) do their stuff and that the team as a whole is maximizing our time. Whenever for some reason something is blocking me that isn't directly code related, he'…
Any senior or lead could handle the planning and the resources. We both agree that there is something to be done. I personally noticed that it doesn't have to be assigned to an full time manager position.
Earlier quoted context omitted.
Care to elaborate a bit? Especially, why do you think unit testing and debugging of SQL is not hard?
> Care to elaborate a bit? Especially, why do you think unit testing and debugging of SQL is not hard? An SQL returns results directly in tables which you can check in all kinds of ways. You can create any number of temporary tables, with the same schema as your business tables, and check all kinds of invariants. There's absolutely no reason why unit testing SQL should be harder than anything else, considering a sing…
Earlier quoted context omitted.
Logic in the Database has the following issues: 1. it doesn't work well with source control 2. deployments, rollback, replication, synchornization - they don't work very well with db procedures 3. unless you connect directly to the db, then you must have some logic on the serverside, usually you end up replicating logic from the db to the serverside 4. Databases languages (even advanced ones like PL/SQL) are not expr…
All of that apart from 5 is totaly wrong
Earlier quoted context omitted.
This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…
Can you explain why you feel that "do everything in the database" is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won't trust anything that only has application level security, and nothing at database level to check/limit it.
Earlier quoted context omitted.
Care to elaborate a bit? Especially, why do you think unit testing and debugging of SQL is not hard?
Care to elaborate a bit? What's hard about it?
You need to prepare test data, you need to update and maintain the test data. That is already a big barrier to entry.
The actual testing involves three simple steps: setting the initial state of the database, run your queries/procs, verify the results. This will be unbearably slow even for a small test set. So you start to make things complicated by trying to be smart, like only revert the state you modified, or using SQLite for tests and Postgres for production, or by running the database server on a RAM filesystem, etc, etc.
I've seen a few people go down the rabbit hole and noone came up with a solution I could be happy with.
Earlier quoted context omitted.
The problem is ensuring deployment matches up. It's very easy to end up with subtle differences between a newly deployed database instance and a database instance that was deployed with an old version and then updated. For code you would think very hard before deploying each version as a patch to the previous version - it's easy and effective to just deploy the code afresh each time, with a complete artifact built fr…
I don't understand what's hard about mass-overwriting your previous stored procedures with new ones. You're right about non-SProc code; just deploy all of it. Do the same thing with SProc code! What's tough about keeping all your code in files that start with "CREATE OR REPLACE FUNCTION ", and just firing them all at the DB (within a transaction, if you like)? I don't actively advocate putting all the code in sprocs,…