|
At my company there are few programmers that are either lazy, non-quality minded, unintelligent or all of the above. I have written a driver and they have to provide a GUI on top of that driver. Normally, my driver would be very thin with no restrictions, but knowing the quality of my co-workers I have added a validation layer on top of the low-level drivers because I care about the success of my company. How would you recommend I minimize the risk that they bypass the validation layer and call the low-level functions directly? Should I encode my variables, function names and parameters, using some kind of ASCII encoding algorithm, so it's difficult to understand what the functions do? Should I name my low-level functions something like KEVIN_JEFF_AND_MARK_NEVER_CALL_THIS_FUNCTION_writeMemory(uint32_t addr, uint8_t value)? Any other ideas? I've already talked to my boss and he thinks it's too difficult to find new programmers to get rid of them.
|
|
|
|
|
You provide them with an "interface" that only exposes the methods and properties that you want them to see. Most programming languages (which you didn't specify) have "interface" patterns.
Designing C# Software With Interfaces - Simple Talk
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
modified 14-Dec-19 13:02pm.
|
|
|
|
|
The programming language is C#. We don't want to use a dll because then we can't step through the code when debugging.
|
|
|
|
|
Dll's don't preclude debugging.
Use a wrapper class then. Give the "bad programmers" the wrapper that calls your dll's "open" methods, then make up a stupid name for the dll that they can't guess: StupidProgrammer.dll, for example. Though they have to add stupid dll to the project too.
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
|
|
|
|
|
make your functions private and call them from the validation layer
|
|
|
|
|
I once had a boss and a coworker focussing on exactly that, afraid I might abuse the "Connection" object.
They spent so much time on it that the project and the money-making VB6 application were both abandoned, ending the company.
Your arrogance is not worth the effort. Lazy programmers are not your main concern. And please, give me the name of your company, so I can prevent asking for work there.
edit--
Hi Ralph!
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
modified 21-Dec-19 18:40pm.
|
|
|
|
|
Change jobs, seriously if you cannot trust your co workers to do the right thing and your boss thinks it is too difficult to get competent developers then your company is doomed.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Don't expose the functions as public then? They should only be seeing the public interfaces you want them to see.
Also start to employ more defensive programming with in those functions, validate all the incoming parameters, and fail early and often if they're not within the spec. If its function order then maybe you could add a audit type layer, so you can ensure function x is called after function y.
Generally though, why would they call a function they don't need? If they're calling it from the GUI then surely there's a spec that says that's what the GUI needs to do? And your driver should be providing a safe method for that?
|
|
|
|
|
Hey! I'd like to ask the technical community about project architectures.
What advantages and disadvantages do these types of architecture provide?
When it's better to choose serverless? When SOA? In what cases should you prefer traditional architecture?
Please, share in comments and thanks for your opinions!
|
|
|
|
|
Darina Smartym wrote: What advantages and disadvantages do these types of architecture provide?
As described on Wikipedia.
Darina Smartym wrote: When it's better to choose serverless? When SOA? In what cases should you prefer traditional architecture?
The type of application usually requires a specific architecture; it's hardly like we "choose" serverless when writing a notepad-type of application.
If you want to know which one is applicable, you'll need to study them.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: As described on Wikipedia.
Eddy Vluggen wrote: you'll need to study them.
True, but this IS a discussion forum. 
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
ZurdoDev wrote: True, but this IS a discussion forum.
I don't mind a discussion; but asking which to use when is not a discussion.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Darina Smartym wrote: When it's better to choose serverless?
Everything we do at my company is severless because we don't want to have to deal with hardware in any way. We do, of course, have a laptop, but that's it.
The architecture you choose depends on what the business requirements are.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Got some time left, so revisiting this thread. YOU wanted the discussion.
ZurdoDev wrote: Everything we do at my company is severless because we don't want to have to deal with hardware in any way. We do, of course, have a laptop, but that's it.
According to that idea, "calc.exe" has a serverless architecture, which is ofcourse, nonsense.
For any desktop app that doesn't communicate, "serverless" is a side-effect, not the main architecture.
One still has to learn about the pro's and con's of every option to make an (informed) choice.
CSLA is a nice option for WinApps, which isn't helpful for calc.exe either. Still works wonders for some applications.
Stuff becomes interesting if you have multiple options; imagine chat - could be serverless, ofcourse, but also could be using CSLA for the UI, and could be completely SOA. So how would you even call that?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I'm not sure if you're aware of the marketing buzzword version of "serverless" that's currently being pushed by cloud providers - mostly products that are quick and cheap to get up and running (not to say anything about ongoing costs and vendor lock in). Given the mention of SOA I'd guess the OP has been reading a lot of things about how to build "modern", "cloud-native" applications.
|
|
|
|
|
Dar Brett wrote: I'm not sure if you're aware of the marketing buzzword version of "serverless" that's currently being pushed by cloud providers
I wasn't  , and that isn't; if you use the cloud, you're depending on a server. Granted, not your own, but it is not "serverless". Peer-to-peer is.
Dar Brett wrote: Given the mention of SOA I'd guess the OP has been reading a lot of things about how to build "modern", "cloud-native" applications.
A buzzword-magazine then, not a book on coding.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: I wasn't , and that isn't; if you use the cloud, you're depending on a server. Granted, not your own, but it is not "serverless". Peer-to-peer is.
You're preaching to the choir 
Obligatory XKCD[^]
|
|
|
|
|
Q:
Does it make sense to have multiple resource files per culture, to organize things into logical groups (in opposition to one monolithic file per culture)? I'm thinking things like Labels<.culture>.resx, ValidationMessages<.culture>.resx, etc
Details:
Just getting into localization for the first time. (C#, MVC if that's important).
Created a little POC form where I had ResourceTest<.culture>.resx files as embedded resources. Decorated model properties with some data annotations to display the label for the field, a required field message, made the button text vary with the culture, simple things like that. That seems to be working o.k.
Thinking about applying localization to the entire application, it seems as if a single resource file per culture could get huge and unwieldy, so I thought it might be smart to have several .resx files per culture, to make it easier to find existing names/values. Not married to the idea of "functional areas" to group the data.
Doing some googling around, I couldn't find any best practice (or not) on this idea.
What say you, CP?
|
|
|
|
|
I'm using "embedded resources" and with data compression my "data" is less than 1/3 compared to uncompressed. Decompressing the "resource stream" at run time.
The resources were .net "content" objects that were created, then binary serialized, then compressed, then embedded.
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
agolddog wrote: What say you, CP?
I'd say you not the first to globalize an app.
Globalization | Microsoft Docs[^]
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I believe that localization should take place where it's highly necessary. Multiple resources will only make things complicated. Keep it simple.
|
|
|
|
|
Hi ,
I have designed 4 layered C# application.
Few of the forms i need to load few dropdown in page load event.
In Leagacy way we put all select query in stored procedure and load all dropdown at a time.
for example
when load customer, products, cities in invoice page
Select * from Customer
Select * from products
Select * from cities
put all qauery in on SP then load all dropdowns in page load.
in oops design
GetCustomers
GetProducts
GetCities
all separate methods and when we call each method hits database call
3 times server call will happen. Is that right way or any other efficient way is available
please suggest me
Regards
Elavarasan
|
|
|
|
|
"Select *" is the lazy man's approach; expect your apps to perform the same.
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
I differentiate between static/master tables and dynamic data. Cities I would load the first time it is required and cache the collection so it only loads once, not every time you hit the page. Customers I would expect to change more often and I may load it every time you hit the page.
I would never use a single SP to load multiple tables, I once tested it and it was dramatically slower than using a single proc per table.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Can it be done YES, is it appropriate probably not.
First I STRONGLY suggest you NOT use select * its really a lazy way to do things
Second if your going do do it you have to return a DataSet not a DataTable in your ADO Call
Then your proc would look like this
Create procedure dbo.myproc_GetParameters as
Select id,name from Customer
Select id,name from products
Select id,name from cities
Then set.Tables[0] will be customers set.Tables[1] will be products...
This is a LOT of data to pull at once and poor performance...
Your MUCH better off to pull them individually in separate calls
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
