|
A looong time ago, as part of a middleware builder I wrote, it would generate SQL-DDL scripts to create tables and the stored procedures necessary to access them.
One of the things it did was use text cursors to run regular expressions over fields to validate them. Basically, it generated the SQL code to use a table based state machine to walk the fields and validate a regular expression so that if you passed a phone number or an email address in as a string it would reject invalid candidates.
The same thing happened at the middle tier, and at the front end web page, so no matter how you hit it, it would *not* let you put invalid data in the database.
I've almost never seen this done in practice elsewhere, but it has been a long time since I've done this kind of development professionally, and I was wondering how common a practice it is (maybe using some of the newfangled SQL Server features for example) to do granular field validation like that?
One reason I ask is because I have a tool that can potentially generate the SQL-DDL scripts to do this, but I don't know how useful it would be to people in practice.
Real programmers use butterflies
|
|
|
|
|
Not really, but the applications I work on don't take user input. My responsibility is pretty much just ETLing data from other places into a staging database (mostly with SSIS).
There are some places where we check for IP addresses (in particular), but that's about it.
And to do IP addresses, I wrote a CLR Function which uses .net's System.Net.IPAddress class to convert to VARBINARY(16) or return null.
|
|
|
|
|
Spinning up the CLR/CLI inside an RDBMS makes me feel dirty.
Real programmers use butterflies
|
|
|
|
|
Yeah, baby! 
It's there anyway. And much faster than so many SQL-implemented chores -- text handling in particular.
|
|
|
|
|
A rather similar question came up hear maybe half a year ago. That poster got "corrected" for insisting that browser input validation was enuff.
I would say: that DB-level validation is absolutely mandatory to protect the DB from data corruption. E.g. somebody my try to enter data with their own client (out of malice or just curiosity).
Having data validation-as-you-type is matter of user friendliness. Eg I hate sites that tell you that the password I just entered twice needs more stuff, after having chewed on the entire form for bit.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
megaadam wrote: I would say: that DB-level validation is absolutely mandatory to protect the DB from data corruption. E.g. somebody my try to enter data with their own client (out of malice or just curiosity).
Unless you're in a situation where arbitrary applications can write to your database, serverside validation is sufficient. If you have a big-One company database that dozens of different applications use, well Codethulu help you (because no lesser gods can); and yeah then you probably do need to do validation in the DB.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
One problem is that SQL-implemented routines often perform poorly, so "doing it in code" is preferred. So what about when using a Web Service as the front door to the database -- and not allowing direct access to the database? All clients have to go through the front door.
|
|
|
|
|
That works depending on the situation, and depending on how much confidence you have in your DMZ being adequately hardened.
When the database is on a LAN, things become a bit different, but even if it's hooked to web facing internet servers behind a DMZ there is always the chance your webserver gets hacked, and when that happens, they at least have the same access to the database the webserver does. If the database is hardened with routines like this it can at least limit some of the damage.
Real programmers use butterflies
|
|
|
|
|
Yeah, see? I don't do that Web stuff.  I stay in the back end and keep my head down.
|
|
|
|
|
I *am* talking about the backend. This is a statement about infrastructure, not front end coding. If your DB is on a LAN, there's a good chance there's no DMZ which means a disgruntled employee could poison the database, probably pretty easily, unless there's security on the tables and validation.
Real programmers use butterflies
|
|
|
|
|
At work we need to hire new forces and we will gather Friday to brainstorm about our programming questions for new prospects. There is [approximately] a bazillion bazillion questions you can ask about stuff like stack & heap & RAII & threading & novelties in clang std=c++20 & algorithm complexity and whotnot
But... as time passes I've come to appreciate team spirit more and more. I've seen impressive coders at IQ 180 lightning fast and getting things done in blink. Half of those have been really nice ppl but the other half have been either elephanting primadonnas spreading bile or just loners producing unmaintainable code. So what line of conversation and questions can reveal whether a adequately competent candidate is a true team player? Of course all smarties will say the right thing to naïve questions like "Do you like teamwork?"
Thanks
"If we don't change direction, we'll end up where we're going"
modified 29-Oct-21 4:24am.
|
|
|
|
|
(Only half tongue-in-cheek) Get your short list together and give them a team exercise. Observe closely.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
This is the best answer  I was gonna say something similar but very few places are willing to spend the resources needed to do it.
|
|
|
|
|
Jon McKee wrote: but very few places are willing to spend the resources needed to do it.
Not just that, but a large number of candidates won't be willing to do something like that. To be useful it'd either need to be done with everyone on and interacting at the same time, or really extended in time to generate a useful number of async interactions. The former is a scheduling nightmare if done outside of working hours, and will largely exclude the currently employed if done within them. The latter being an even bigger time suck will have more people noping out; and while you could try to counter that by offering to pay participants for their time, that would run into various moonlighting restrictions (either bans or mandatory disclosure/approvals to avoid conflict of interest risks) for people who are looking to change jobs.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
True. I think it could be done near the end of the process assuming you're allowed to schedule outside of 8-5 and the candidate list either is all +-2 timezones or can be grouped into buckets like that. As far as willingness, a lot of engineers don't like the idea that our entire skillset is boiled down to whether we know the one trick for an optimal solution to a competitive programming question and yet we have to deal with that still. To be fair that's probably not everywhere but it does seem to be a growing trend.
|
|
|
|
|
Guaranteed to yield the cleverest bully 
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
You need to define "team player" first. Every person has a different idea of what that means. Once you have a concise idea of what that means to your team, you'll have a list of traits to look for in a candidate. Tailor your questions to indirectly give you an idea of whether they have that trait.
So if one of the traits is "willingness to pick up another person's slack" or "ability to work with difficult people", ask them about a time they were on a dysfunctional team and how they approached that problem. Or something like that.
That's how I'd approach it at least. It's difficult though because candidates are conditioned to appear perfect at all times or have their applications thrown in the dumpster. Just like candidates are conditioned to place a greater emphasis on competitive programming skills than actually being able to write readable, maintainable code. In both cases, the former gets you a CS/SE job while the latter gets you a job at McDonald's.
Just my anecdotal opinion though as a professional interviewee.
|
|
|
|
|
PHBs think "yes men" are "team players", but they're not.
|
|
|
|
|
Yep. It takes way more investment in the team, product, etc to disagree.
|
|
|
|
|
Jon McKee wrote: Tailor your questions to indirectly
Exactly that tailoring is what I meat to ask about.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I would think about the ways they can answer your question and try to ensure answers will fall into a useful range. Try to answer the question yourself and if a lot of experiences come to mind that would be irrelevant to what you want to know about the candidate then rework the question - be more specific, change the scenario, or change the perspective (e.g. failed vs succeeded at a task).
|
|
|
|
|
A lot of universities now assign projects that are done in teams. If a candidate worked on such a project, you could ask open-ended questions, such as what they liked and disliked about the experience, or what they believe are the advantages and disadvantages of working on a team.
However, I wouldn't over-emphasize teamwork. Development is often done alone, and poor software drags everyone down regardless of how well its author gets along with others. Teamwork involves things like sharing information, constructively participating in design and code reviews, and helping to get new staff members up to speed.
|
|
|
|
|
With just some questions it's probably hard and unreliable. If feasible, I'd suggest a test where you give them a piece of oldish software, describing what goes in and what comes out and ask them to incorporate a new feature.
Primadonnas will be tempted to through away all the old code and write everything from scratch (because their code is best). Others may prove utter incompetents who cannot do any work and, if you are lucky, you might spot some that can treat a piece of code with respect and adapt their way of thinking to blend in with what's already there.
Mircea
|
|
|
|
|
I've never heard the "team" use the term "team member"; only management: "He or she wasn't" (whatever that means). I think it means being part of the herd.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Or being a doormat. The term is sometimes a red flag.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
