|
Myself I realize that humans are messy and disorganized. There are no good ol' days where that wasn't true. Someone probably died because the wedge they used on a block when building an Egyptian pyramid was the wrong size.
Now selective memory on the other hand is true. They have proven that.
|
|
|
|
|
I know exactly how you feel. I worked in IT for a small, very specialized group in a large (5000+) corporation. Fortunately my group maintained the hardware/software for a corporate core function (AGC/SCADA/electric utility). As such we were insulated from the rest of the IT insanity. Eventually to further insulate us we were removed completely from IT and put directly under the engineers in charge of transmission/distribution (another hell, but at least a lesser one).
|
|
|
|
|
Greetings,
as Mark Twain once stated:
“Never argue with stupid people, they will drag you down to their level and then beat you with experience.”
Cegarman
document code? If it's not intuitive, you're in the wrong field
|
|
|
|
|
Much like my days with Orange Mobile Comms.
I was a GSM/Radio Access/Network Engineer, and we had for anything I.T.to have to call the I.T. team who sat at the other end of the office from us.
In fact most times, I could ring "I.T. Support", look over the divider and watch someone pick the phone up and answer it.
The funny part was, I.T. support had to get permission from the network engineering teams to enter the data centre's and server rooms, so we could quite often phone I.T. support, watch the call get answered, then watch that person make a call to "Network" which would then ring on the phone beside me, which I would then answer and confuse the hell out the person on the other end.
Nothing ever got done, because we spent more time following process than getting anything done.
So upper management thought it would be a great idea to combine the Network Teams, and the I.T. support teams into one large "Tech Operations" team.
Not for one moment did they consider that the engineers on the Network teams where also high access certified (We looked after all aspects including GSM, and that often meant climbing phone masts) they just looked at it from the point of view that we "The Network Team" where just specialised I.T. Monkeys that did "Networky Stuff".
So all of a sudden you had all these general I.T. support guys suddenly being sent out into the field and not having a clue what they where doing, and experienced guys who should have been out in the field answering support calls to fix printers in managers offices.
It get's better though......
So to FIX that problem, they removed field work from all I.T. & Network personnel completely, made us all sit answering phones all day, then farmed out the actual work to a 3rd party company, costing them 3 times what they paid the already trained trained guys that where on the payroll, then they set up a help line for the contractors to phone into the I.T. help desk to help them when they didn't know how to do something on the network or on any I.T. problem inside the organization.
Stuff like this just never ceases to amaze me.
|
|
|
|
|
Like Hecklefish said the other night, "If we are going to rely on Humans to teach AI morality, we're screwed..."
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
If they used Nutanix, they wouldn't run into that problem as it takes in all of the hypervisors.
|
|
|
|
|
There's a reason we were happy when the Personal Computer was created. We got away from the admins of the mainframe.
IT managing lots of users is easier if they can standardize on processes. The standards they pick work for most people (accounting, sales, shipping/receving....) Software & firmware engineers are an edge case of their user base.
|
|
|
|
|
Wordle 747 4/6
⬛⬛⬛⬛⬛
⬛⬛⬛🟨🟨
🟨⬛🟨🟨⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 747 5/6
⬜🟨🟨⬜⬜
⬜⬜⬜⬜🟨
⬜🟩⬜⬜🟨
⬜🟩⬜🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 747 4/6
⬜⬜⬜⬜⬜
⬜⬜🟨🟨⬜
🟨🟩⬜⬜🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 747 5/6
⬛⬛⬛🟨⬛
⬛⬛⬛⬛🟨
⬛🟩🟩🟨⬛
🟨🟩🟩⬛🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 747 4/6*
⬜⬜⬜⬜⬜
⬜⬜🟩🟨⬜
🟨🟩🟩⬜🟩
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
⬜⬜⬜🟨⬜
⬜🟩⬜⬜⬜
🟨🟩⬜⬜⬜
⬜🟩🟩⬜🟩
🟩🟩🟩🟩🟩
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 747 3/6*
⬜⬜⬜⬜⬜
⬜⬜⬜⬜⬜
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
|
|
|
|
|
Wordle 747 4/6
⬛🟨⬛⬛⬛
⬛⬛⬛🟩🟩
⬛🟩⬛🟩🟩
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 747 5/6
🟨🟨⬜⬜⬜
⬜🟩🟩⬜⬜
⬜🟩🟩⬜🟩
🟨🟩🟩⬜🟩
🟩🟩🟩🟩🟩
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Back in 2009, I began a personal project, using SQL Server (Express) and -- after a month or two -- got it to a certain point before losing interest.
Around 2014 (if I recall correctly), I had the idea of reworking it to use SQL Server or SQL Server Compact depending on what the user specifies at run-time.
This is not difficult. If I recall correctly, Subversion can be configured to use one of two (?) database backing stores.
I have long sought a project to show off my ideas about implementing an SQL-based application which can be configured to use any one of a number of supported ADO.net providers. I just didn't want to expend a lot of effort on it at that time. Yet it has remained in the back of my mind.
This summer I have some time to have another look at it and I see that SQL Server Compact is currently out of support.
(As with OleDB, I hope Microsoft reconsiders and releases a new version, but I'm not holding my breath.)
As you may know, I don't really care that something is out of support, but finding some other product is still desirable.
What I envision is the ability to have the application, it's data file(s), and whatever DLL(s) is required on a flash drive, and just run it from the flash drive on "any" suitable Windows PC -- not relying on the host to have anything more than a vanilla .net install.
What I am looking for:
SQL-92 compliance
ADO.net provider
No software/driver to be installed on the host
From my few experiments, SQL Server Compact satisfies all of these criteria.
From what I can tell, SQL Server LocalDB does not meet all of these criteria -- but maybe I misread something. Of course, I could add support for that as well anyway.
I have looked around online a bit and not found anything which seems to be what I want.
The term "embedded database" comes up a lot, but I don't want NoSQL or a Key/Value store or anything which must be installed.
I will likely proceed with using SQL Server Compact and add support for other systems as they come to light. This particular application is really just a proof-of-concept anyway.
I just wonder whether or not anyone here knows of something I've missed.
|
|
|
|
|
I don't know how SQL-92 compliant it is, but have you tried SQLlite?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It's mostly compliant. Biggest deviation is that it's weakly typed and has limited support for triggers
|
|
|
|
|
Thanks.
I hadn't noticed that an ADO.net provider was available.
I am a little concerned about the lack of SQL-92 compliance, but I don't use triggers and some of the other features (it) lacks.
The typing system may be an issue, yet it may not be.
|
|
|
|
|
Sounds as if (unless I've misunderstood) that you've got two separate requirements:
1. Build an app where you can just "plug in" any suitable datastore at runtime.
2. Build an app that has no dependencies on any dbms already existing, just install and run a single package
#1 is basically around separating out logic and data access layers; the .Net apps I write have a separate data layer that is provider-agnostic and just tweaking a single constant switches between MySql, SqlServer, Postgres etc. The value could just as well be provided at runtime.
#2 Once you've done #1, #2 becomes easier as there's no "dependence" in the app on SQL standards, since that's all the "other side" of the separation. Hence I can swap MySql for SqlServer (though the d/b does need to have stored procs that manage the database logic - queries etc). You could even consider embedded MySql (runs on Win10/11, and Win Server 12/16/19/22)
|
|
|
|
|
DerekT-P wrote: embedded MySql
Thanks. I'll have a look, I don't recall seeing it my searches.
1) Not entirely, though I could do that. I have done plug-ins before, but this would be that support for multiple providers would be built-in and then selected at run-time.
2) I would want to be in control of which providers are supported.
Plug-ins are generally done with Interfaces, which can lead to a bunch of duplicated boiler-plate code. What I do for supporting multiple SQL providers avoids that. Which is the point of this exercise -- to show a working example of this technique.
|
|
|
|
|
Probably my naff terminology. I have a data layer that uses generic Data objects (System.Data.Common.DbConnection, d
DbDataReader etc) and then a very simple factory class that, dependent on a single parameter (which could be provided at runtime) returns a MySqlConnection, or a SqlConnection, etc in that generic object. So long as the datastore supports stored queries and parameters the app doesn't care what it's talking to. But it does necessitate the database being populated with table structures and SPs.
Probably getting a bit programmy for The lounge...
|
|
|
|
|
DerekT-P wrote: a bit programmy for The lounge
Possibly.
I program to the Interfaces, and ADO.net takes it from there.
The two things to consider are instantiating the correct IDbConnection, and then any variations in the SQL statements.
|
|
|
|
|
the biggest drawback to "separating your data layer" idea is that people forget just how much logic is baked into their SQL calls.
people are writing business logic in their SQL. the challenge is to see if you can "separate" that into a layer.
the only idea I had was DSLs. those are really hard to implement.
this is why i can see someone wanting to keep the sql and switch the implementation.
|
|
|
|