He might have been thinking of JavaScript. You can never tell since members here seem to confuse the two constantly and the post was near other posts discussing the scripting language.
Printable View
He might have been thinking of JavaScript. You can never tell since members here seem to confuse the two constantly and the post was near other posts discussing the scripting language.
Oh i completely understand that i have read the info on it but even so being able to create apps in .NET which can be multi platform is only a positive in my opinion.Quote:
But .Net Core has a different purpose than the .Net you know. It has no WinForms, no WPF, no lots of things.
What i would be really nice for me personally is hosting ASP.Net solutions on Linux with apache.
I find IIS horrible to use and would much prefer to host all my web stuff on apache on linux.
I've had my issues with IIS as well.
What do you find better in Apache?
Even so , why a computer language needs to die?Quote:
Originally Posted by dilettante
No matter if it’s going to happen quietly or not.
Some out there use it. If anyone don’t want it , just don’t use it.
That simple.
P.S. Now I get the “quietly” part. Some other language failed to die “quietly”.
Because it does nothing for the end user except create a maze of frustration and perpetuates the 'computers are hard to use and just break sometimes' situation. It's a language that exists purely for the languages sake. It does nothing - absolutely nothing - well, and attracts those who can't program worth a damn; and that includes those who stick to the philosophy of 'pure programming' - the worst kind of a-hat that needs to be fed a diet of their own special kind of crap.Quote:
Originally Posted by JackB
Can hardly stand not answering it. :cool:Quote:
Originally Posted by szlamany
Quote:
Originally Posted by SJWhiteley
Let me ask you. What makes you think that the “end user” cares ?
Maybe it is the way all remained pure MASM devs (if any) think of all of us.Quote:
Originally Posted by SJWhiteley
This is Java syntax from an Android app I have - it's terrible - .equalsIgnoreCase() instead of just "="? The primitives of the language are rough to say the least.
Code:JsonObject ResultObject = JsonObject.readFrom(result);
for(String name : ResultObject.names())
{
if(name.equalsIgnoreCase("Type"))
{
if(ResultObject.get(name).asString().equalsIgnoreCase("Login"))
{
Toast.makeText(getBaseContext(), "Data Sent!", Toast.LENGTH_LONG).show();
if(!LoggedIn)
{
if(Controller.LoginParser(json2))
{
LoggedIn = true;
LoginResults = json2;
login.CallPostBootControls();
}
else
Yes, because some languages are case sensitive, not only in the language, but in the data...Quote:
.equalsIgnoreCase() instead of just "="?
So...
ResultObject.get(name).asString().equalsIgnoreCase("Login")
will fail if it's LoGiN... or login. so the equalsIgnoreCase means no matter what the casing is of the data, LoGiN and login will equal Login...
it's like doing this:
ResultDataRow.GetString(name).ToLower = "login"
it's ensuring it's apples to apples and lemons to lemons.
-tg
Obviously...
My point was that = is not allowed you have to use a method
Right, because = is an assignment, while == is the comparison operator... the reason to use a method is to be explicitly clear that the comparison is case insensitive...
I sit corrected... according to this comment I found on SO -
I guess in Java, everything is a reference object as opposed to a value object... huh.Quote:
Use the string.equals(String other) function to compare strings, not the == operator.
The function checks the actual contents of the string, the == operator checks whether the references to the objects are equal. Note that string constants are usually "interned" such that two constants with the same value can actually be compared with ==, but it's better not to rely on that.
-tg
I really, really, really don't like attacking a random code snippet as indicative that a language is terrible. Java certainly has some technical shortcomings, but good developers can work around them with different patterns.
I think the example has some poor concepts. The first thing I'm upset about is how deeply nested the ifs get. Then I ask, "What exactly does Controller.LoginParser() do, that's not a verb!" And I'm curious why we don't want to show a "Data Sent!" notification unless we specifically notice there's a "Type" : "Login" pair in the result. It makes no sense to me as-is because it's poorly structured. That's not Java's fault.
We could transcribe it directly, and it'd still be butt-ugly. Here's a representative snippet made "better" in VB:
I can't even tell I'm not reading the Java. This code stinks not because of "equalsIgnoreCase()", it stinks because it focuses on "how" instead of "what". We shouldn't write code that way. This is what it could look like in Java and be beautiful:Code:If ResultObject(name).ToString() = "Login" Then
NotifyIcon1.ShowBalloonTip(10000, "", "Data Sent!", ToolTipIcon.Info)
If Not LoggedIn Then
If Controller.LoginParser(json2)
All the "ugly" code is still there, hidden behind the facade of code that tells you WHAT it is doing rather than HOW.Code:notificationService.DisplayMessage("Data Sent!");
var result = JsonResult.FromJson(result); // Uses the parser, but converts JsonObject to something I want.
if (result.MessageType == MessageType.Login) {
AttemptLogin();
}
But even if it were ugly, let's talk about .equals() and .equalsIgnoreCase() vs. "just ==".
First, if you care about a case-insensitive compare, there's no way to tell VB to do so with just the operator. You have to do something like this:
That's not anything near as intent-revealing as equalsIgnoreCase(). How's VB .NET pull off a case-insensitive comparison?Code:If value1.ToUpper() = value2.ToUpper() ' BARF
Real slick. ;)Code:Dim valueEqual As Boolean = String.Compare(foo, bar, StringComparison.OrdinalIgnoreCase) = 0
The problem is not that "=" is not allowed. The problem is that in Java, "==" is strictly defined as a reference equality operator, and when you compare strings you want value equality. Since it's consistent across the entire language, you can just learn "comparing things with == is usually wrong" and go about your business. The story in .NET is much more complex. .NET did not strictly define the == operator as having value equality. Instead it opted for a set of rules, and the end result of the rules are this:
"To know what "==" does for an arbitrary type, check the documentation. It's usually value semantics for value types and reference semantics for reference types, but the default value type algorithm is sometimes wrong and in all cases Equals() might be overridden to have special rules. By default, you can't use operator== to compare two reference types. For strings, sometimes things get weird, and you shouldn't rely on reference equality alone."
That last bit's fun to demonstrate. Try and guess what this prints, then run it and see if you got it right.
Code:Sub TestStrings()
Dim value1 As String = "asdf"
Dim value2 As String = "asdf"
Dim value3 As String = ""
value3 &= "as"
value3 &= "df"
Console.WriteLine("Does value1 = value2? {0}", value1 = value2)
Console.WriteLine("Does value1 = value3? {0}", value1 = value3)
Console.WriteLine("Is value1 the same object as value2? {0}", Object.ReferenceEquals(value1, value2))
Console.WriteLine("So value1 and value3 are the same object? {0}", Object.ReferenceEquals(value1, value3))
End Sub
That code was written by someone that lasted here about 5 weeks - fresh out of college. That's what a headhunter got me...
It was only ever supposed to be a prototype and the client liked the look and feel of how it ran.
Now I've got to make real code out of it and my only experience with Java was watching this kid code. I remember fighting with him that "no one would use a method to compare a string - something you do on every other third line of code!). Apparently it does in the Java world.
There is so much taken for granted with the little old "=" symbol in VB. Does it compare - does it assign - how do I bit-check with and/or's. Maybe it's because the LET statement is assumed.
I think this is a bigger point than just VB. Maybe it's just me but I seem to be noticing a general trend toward imprecision in languages and I don't like it. In my last contract I worked in Python alot (seems to be all the rage in the Data Science world) and I hated how I had to wait until runtime before I could find out I'd just assigned a string where I wanted an integer. Gah! I've been teaching myself MVC and all the examples I find type everything as a var. I'm guessing that's a throwback to JavaScript but I see this even in controller examples and they're in C#. Even bigger Gah!Quote:
There is so much taken for granted with the little old "=" symbol in VB
I like languages that force me to be exlpicit. They keep me safe.
Edit>@TG and Sz, I'd been meaning to come back on your UI in the DB aproaches. 1. Nice work 2. Does this cuase any problems if you want multiple GUIs. I imagine you could support that by keeping multiple GUI definitions (for want of a better description) in the DB but I'm also willing to bet there's a sting or two in the tail that I haven't thought of. Is this something you've ever had to support and, if so, what were the hurdles?
One of the reasons I'm interested is that this aproach is simailar (in philosophy at least) to something I was trying recently and ultimately gave up on (at least for now - I may revisit it). I wanted a system where the major entities types were preset but the customer could define what those entities looked like, not just the UI but their properties. I tried an xml aproach where an xsd doc defined an entities schema, and xml doc defined an instance of an entity and an xslt doc defined how an entity would be presented on screen. These were all held in xml fields in the database. I think you're aproach is smiilar (in philosophy) to the xslt element of that set up.
4GL is what this is called
https://en.wikipedia.org/wiki/Fourth...mming_language
I make the base UI as simple as possible - with my web app it's a div called SYSTEM containing 4 div's arranged in a 2 x 2 matrix (top row BINDER, OPERATOR and bottom row TRACKER, WORK). These 4 div's are sized to look like your typical explorer-window with TRACKER being you object viewer and WORK being that big empty space)
All these DIV's are empty when the user gets on the page and the login popup appears.
After login the AWCConfig_T table shown below is returned in a boot-up sequence.
The ROLEID column has a number of a role that must be associated with that USERID that just logged in. This is one method I use to supply a different UI experience to different users.
Type "1" items below fill the OPERATOR space. The AWCWhat controls what is drawn - "button" is the only item supported at the moment.
Type "2" items tell the TRACKER "what to be" - the only option at the moment is a jQuery "accordion" - but I still drive it from the DB.
KISS means I have one source of UI meta data.
Type "3" items tell the TRACKER what to fill up with - basically a panel in each accordion.
You will see lots of JSON-strings that get EVAL()'d into native JavaScript variables. Some have k/v pairs needed by those UI elements - others have additional k/v pairs I need for logic hooks.
Then I have type "4" items to fill those corresponding panels - support DROPDOWN and AUTOCOMPLETEID.Code:AWCType AWCSeq RoleId AWCWhat Element AWCId AWCOptions
1 1 3 1 button btn-tasks { "text": "true" , "label": "Tasks" , "icons": { "primary": "ui-icon-clock" } }
1 2 5 1 button btn-vital { "text": "true" , "label": "Vital Statistics" , "icons": { "primary": "ui-icon-clipboard" } }
1 3 5 1 button btn-inspections { "text": "true" , "label": "Inspections" , "icons": { "primary": "ui-icon-clipboard" } }
1 4 5 1 button btn-complaint { "text": "true" , "label": "Complaints" , "icons": { "primary": "ui-icon-alert" } }
1 5 5 1 button btn-investigation { "text": "true" , "label": "Investigation" , "icons": { "primary": "ui-icon-star" } }
1 6 5 1 button btn-snap { "text": "true" , "label": "Establishment" , "icons": { "primary": "ui-icon-home" } }
1 7 5 1 button btn-qfo { "text": "true" , "label": "Food Operators" , "icons": { "primary": "ui-icon-cart" } }
1 8 5 1 button btn-housing { "text": "true" , "label": "Housing List" , "icons": { "primary": "ui-icon-home" } }
1 9 5 1 button btn-septic { "text": "true" , "label": "Septic Systems" , "icons": { "primary": "ui-icon-arrow-4-diag" } }
1 10 5 1 button btn-project { "text": "true" , "label": "Projects" , "icons": { "primary": "ui-icon-wrench" } }
1 11 13000 1 button btn-report { "text": "true" , "label": "Reporting" , "icons": { "primary": "ui-icon-note" } }
1 12 13000 1 button btn-display { "text": "true" , "label": "Displays" , "icons": { "primary": "ui-icon-calculator" } }
1 13 1 1 button btn-users { "text": "true" , "label": "Users" , "icons": { "primary": "ui-icon-person" } }
2 1 0 1 accordion trackerpanel { "collapsible": true , "autoHeight": false }
3 1 3 1 panel acs-task
3 2 3 1 panel acs-taskaddress
3 3 3 1 panel acs-establishment
3 4 5 1 panel acs-compwho
Note that I also have a SPROC name column in this table with optional prefix of ASYNC/ and optional parameters at the end.
Recently one of my clients had a need that I could not address through this setup. They are fine with all this for the in-house intranet version of the web app, but they also wanted a public facing version where vendors could connect and download bid specs for city jobs (argh - two IIS servers that I have to remembers to keep up-to-date with changes - I always forget that other one).Code:4 1 3 dropdown awcTask_autocompleteid @username { "minLength": 0, "choice2": "Check Here to Show All Tasks" }
4 2 3 autocompleteid async/awcTaskAddr_autocompleteid { "minLength": 0 }
4 3 3 autocompleteid async/awcEstablishment_autocompleteid { "minLength": 0 }
4 4 5 autocompleteid async/awcNonEstablishment_autocompleteid { "minLength": 0 }
4 5 5 dropdown awcSelectComplaint_autocompleteid @username { "minLength": 0 }
4 6 5 autocompleteid async/awcHousing_autocompleteid { "minLength": 0, "choice2": "Check Here to VIEW all addresses" }
4 7 5 autocompleteid async/awcHousing_autocompleteid { "minLength": 0 }
4 8 13000 dropdown awcReportNames_autocompleteid @username { "minLength": 0, "btnDefault": "report" }
4 9 13000 dropdown awcDisplayNames_autocompleteid @username { "minLength": 0, "btnDefault": "display" }
4 10 3 dropdown awcStaff_autocompleteid @username { "minLength": 0 }
At any rate for this situation I have a SiteSettings.JS file that the page loads early so that the DOM-READY event (FORM LOAD for you VB'ers) has additional meta data for initial screen setup.
And of course this is a JavaScript OBJECT with k/v pairs I can read up front and make UI elements hide.Code:// Include Site Specific settings below
var g_sitesettings = { RegisterLogin: false, HideBinder: false, SkipFilters: false, HideTracker: false, HideOperator: false, SingleTab: false, OperatorOpen: false };
//var g_sitesettings = { RegisterLogin: true, HideBinder: true, SkipFilters: true, HideTracker: true, HideOperator: true, SingleTab: true, OperatorOpen: true };
Vendors only see the WORK space and they get the OperatorOpen by default without hitting a button. They also have a REGISTER login popup since they can register via there email address.
I've got another table called AWCMobileConfig_T that tells my Android app how to boot up and maintain data.
@Funky - what do you mean by multiple GUIs? In our case our GUIS are defined by the GUID assigned to the XML meta data... so on a form, I can link an element or action to a specific GUID that defines the form to open. When I want to add a field to the form, I create an extension form, and define the parent ID as the ID from the original form. The system framework, when it goes to load a form, will load it, then look to see if there are any extensions that need to be loaded, then looks for any add-ins (non-GUI extensions) and loads them... then it renders the UI as per the loaded specs and displays it to the user.
-tg
As in, you want different classes of users to feel like they're using a comlpetely different app, albeit one that shares the same database and business logic layer.Quote:
what do you mean by multiple GUIs?
E.g. I worked on a marketting app a while back (it was desktop based so I apreciate the metaphor may break down a bit but it should suffice). We had several GUI executables. One for salesmen, one for the marketting department, one for the call centre and so on. These all shared the same business logic layer (we wanted that consistency of behaviour) and data but, from the users perspective, they were different applications. They had different look and feels, they were diferent exes etc.
I was curious whether you'd had similar requirements or whether you treat the whole application as one entity.
It was a few years ago when i used it but its just much easier to setup your website on Apache, you just edit a few lines in the Apache .config file, there is no confusing GUI interface like IIS.Quote:
I've had my issues with IIS as well.
What do you find better in Apache?
I built myself a Linux server put Apache on it (which was much easier than i was expecting) and then deploying a new version of my web application was just a case of pushing the new files to the server and doing an Apache restart. I had pretty much automated it to so it was sooo simple.
I know you can do similar things with IIS but i often have issue with automated deployment to ISS so i don't bother with it.
Also i didn't have to touch the server in 2 years apart form to push a new version to it, it just ran and ran. (that's more with it being Linux than Apache but the 2 come together really)
In our case it can be done... part of the meta data in the XML is a security folder. from the admin side you can grant or revoke access to different forms. So... if you need an admin form and a "user" form, they would be two specs in the system... then you would simply explicitly revoke access to the admin form for the user role, and explicitly grant it to the admin role. When an admin loggs in, they see the two forms, they can open either one up ... the typical user though would only see the one. Users only see the things they have access to. We can also manipulate the UI based on securoty context. We did that recently where the client wanted field-level securty rather than form level.... ungh... but OK... so in an addin for the form, we get the user context, find out if they had accces and if not, we set the fields to read-only. We also have the ability to use expressions in the Visible property of different elements on the UI... So tabs for instance, we can set a tab visible based on a filed value that comes back from the database. We use this a lot where we want to have one form across multiple dataviews because they are common to each other --- example: Employees and Managers... essentially they are just different classes of people... so we could create a single form with a bunch of tabs that they would use, contact, bio, projects, etc. But a manager is going to have Reportees... the employee won't... so the .Visibile field of the Reportees tab would be something like: "=FIELDS!IsManager" ... and IsManager would be a field that's returned by the expression stored proc for the page.... so if they are a manager, it will make the tab visible... if they are not, it will hide it.
-tg
I read a little more about your example - we would develop that in one app - each of those segments would be an "Area" which then consists of modules for specific functionality.Quote:
Originally Posted by FunkyDexter
So, we have a Marketing area... within it, we have Campaign modules, Appeals, Letters, and so on... as I previously mentioned, you can grant/revoke access... so the marketing people will see the Marketing modules, but not the Admin or Revenue modules... the accountants would see the Revenue and Fundraising, but not the Marketing... the call center would see the Constituent (people) modules, parts of the Revenue and parts of the Marketing (so they can answer calls when they come in)...
-tg
As tg said - one app. In my case CONFIG differences based on user role and/or sitesettings config's
Even when I did my last VB.Net traditional WinForm (not 4GL) I still had the sales and CSR and manager versions in one app.
One app satisfies my DRY needs...
Which is basically the whole point of separation of 'layers'.Quote:
Originally Posted by FunkyDexter
You effectively have your interfaces 'task based' determined by the user of the system at a given point; don't show the user information that has no relevance to the current task.
My biggest issue with the multi-exe approach: maintenance. Consider my example, where we have a revenue data that is shared between the call center and accountants... if I want to make a change to a screen to show some additional data, I would only need to do it once... but with FD's setup, it would have to be done multiple times... O.o The accountant and the call center person may arrive at the same page differently, but the change still only needs to be done once. And I don't know about anyone else, but there always seems to be that ooooooone person that wears multiple hats, if everything is contained in a single app, then it's easy to give them access to the different areas they need, w/o sacrificing the security of other users who aren't supposed to have access.
-tg
Explicit vs. implicit typing:
I think if you write clean code it doesn't matter. I go back and forth on this but over my career I think I've spent more time swearing over "look, int to char SHOULD be legal, I just can't figure out the right conversion method" vs. "oh, dang, who would've predicted that 'customers' is an array of customers not a Label?"
I think a lot of people don't care to write clean code. I find those people tend to make the same mistakes in a "type safe" environment as they do in a "type promiscuous" environment, though sometimes they're more "successful" when the compiler tries to fix their mistakes.
I want to say, "The trouble is, they never learn that the compiler is helping them." But I don't know if I agree that they should have to. Consider calculating a percent from two integer values in VB .NET vs. Python:
Which of these looks like something you'd write on the first try? Which of these looks like a complete waste of time? This represents 90% of the "type errors" I get in C#, when I forget that I need to be REALLY explicit about whether I mean for division to be floating-point or not. It is almost never that I am trying to assign an Apple to an Orange variable. It's easy to contrive a case where the Python behavior is wrong, but I'll argue based on my experience that coercing division to an integer result is a more natural idea than coercing division to a floating-point result.Code:Dim percent As Integer = CInt(Math.Floor(CDbl(apples) / CDbl(totalApples) * 100))
percent = apples / totalApples * 100
VB6 trips up its fair share of people with implicit typing, but I like that I can turn it on and off in VB .NET. I don't know if I think telling newbies to always use Option Strict is as healthy as teaching them about writing code that doesn't look sensible when you make the errors Option Strict protects you from. But either way, we do have to teach them a lot about Integer vs. Double and how and when to go back and forth and it just seems useless.
Database UI discussion:
It looks like some form of Presentation Model to me, and the benefits you gain by separating UI from all other logic are manyfold!
Who is teaching them, though? Certainly not the forums or the internet, although they may learn a few things.Quote:
Originally Posted by Sitten Spynne
All these proper (sic) coding techniques generally come from a formalized education. This is where Option Strict comes in. Yes, people should write explicit code right out of the gate, but they don't. No one does, because they don't know what they don't know.
Option strict should always be on for newcomers to VB. Once they understand what it is telling them, then they have the option of turning it off when appropriate. It's a poor substitute for proper education, but at least they should be writing less buggy code.
The fact that you have to 'teach' someone using a high level language the difference between an integer and a double demonstrates that they are a novice 'journeyman' and not a programmer. Because people use the internet as a source of education is why we end up with crappy, buggy, useless programs 90% of the time.
I think this is why VB6 programmers tend to linger on. While I wouldn't necessary go so far as saying that VB6 programmers are, by definition, good programmers, but they learned in an environment where there was no internet or readily available knowledge. They had to rely on books and publications (and not your 'everybody make a book which repeats the help' type books, or 'stupidity for dummies'). They had to actively learn. It's tough to throw that knowledge away, especially to move to a language where the average programmer is [perceived as] a stumbling retard who can't find their way out of room with the door open.
One slightly worrying thing I'm getting (possibly incorrectly) from your replies is that it sounds like your screens are closely tied to your functions. I.e. there one screen and only one screen for entering orders. I would view that as a bad thing because I often want to present several different views on the same function. An order might be entered by a customer, a salesmen in the customer's house, a telesales operator, a back end admin and so on. These guys all want the same business rules applied but what they need from a GUI is very different. A customer wants nicely presented pictures and customer reviews. A salesman might similarly want pictures (to show the customer) as well as a discount calculation. A back end admin probably wants a simple grid with as view keystrokes as possible and no whizzy bits. I'm sure you're already ahead of me on this but do a brother a favour confirm that you haven't ended up creating a single view per function. I'd hate that.Quote:
I read a little more about your example - we would develop that in one app - each of those segments would be an "Area" which then consists of modules for specific functionality.
The other thing that's slightly worrying about your approach (but I don't think is a hard limitation, it could be worked around quite easily) is that it seems limited to providing a web UI. Could you consume this through a desktop or Mobile app? I imagine you could as the sprocs/services/whatever you use to expose the model could be consumed by a different UI. Is that right?
At first glance it sounds like your GUI is strongly coupled to your model and data but the more I look I'm not sure it is. You happen to have stored your GUI in the database but there's nothing intrinsic about that decision that couples them. Could you, for example, keep you GUI definitions in one DB and your business logic and data in another?
One other thing. In my experience sprocs tend to be inherently bad for unit testing. They don't decompose into nice small units and it's very difficult to mock their dependencies. Are you guys doing any form of unit testing (ideally TDD) and, if you are, how were you able to overcome these issues? (It's this, above all else, that makes me leery of sproc based systems so I'd love to hear how others have approached it).
Overall I think this sounds like a good approach. I can see some slight worries and niggles but none seem insurmountable and I can definitely see how it enables quick, RADish turn arounds.
We don't do sales per se... our product is used by the non-profit market - the enterprise types, massive donation raisers, American Heart Foundation, American Diabetes Assoc, Canadian Diabetes Assoc, World Wildlife Foundation, Salvation Army, just to nae a few few - so it's hard to make a fair comparison, but I'll try - the answer is yes and no. there are some cases where we use the same form in different areas - like entering donations - but there are times when we do have a different side of the die showing depending on where you come from. there are two ways of handling that - one is by affecting its bahavior through the context ID (a GUID that provides a "You are here" context. The other is by having a different screen and then determining if it's hidden/shown based on security. so the call center may get the full payment entry screen while someone else gets a slimmed down version even though both accessed it from the same page. Behind the scenes, we'd have two "Add payment" actions, but one is hidden due to security. It makes for fun times when a bug is reported and the developer is in the wrong role and gets the wrong screen. So no, it doesn't have to be one view per function, it can be, but doesn't have to be - case in point, that payment screen I mentioned... I happen to know that there are no less than FIVE of them depending on where you are - I've had to customize them all.Quote:
Originally Posted by FunkyDexter
We sued to be desktop - click once deployment. In 2007 they introduced the web client and went hybrid. In 2012 the desktop/click-once and adopted the web client as the official interface. but we do expose our entire web service - same set of services we use - to any client that wants to know about it and they can even then build their own apps on top of that api and interact with the system.Quote:
Originally Posted by FunkyDexter
No, the UI is not strongly coupled to the data model... anything but... I suppose it could be and in the SDK training it does come off that way, but when you get into the nuts and bolts of it, it really isn't. Could it be separated out into a different database... maybe... but the underlying architecture of the platform would probably need some serious rewiring to essentially read from different databases. What we can do though is easily separate the application (IIS) server from the database server. In fact I have one client that not only is doing that, but their application servers are part of a farm, as is the database server.Quote:
Originally Posted by FunkyDexter
At our level, we don't use unit testing or any testing process (other than yep it works and send it off to QA for testing) it's more functional testing. The products team does use a more formalized testing process... I'm not sure what they use exactly, I but I do know they have something. Sprocs themselves wouldnt' get tested, but the exposed service point would... whether that taps a stored proc is irrelevant - even in TDD the end point is what would be wired up to the harness... eventually that end point might talk to a stored proc, and if that sproc fails, the end point fails the test as well... so if it passed the test before, then failed after adding the sproc, then you know the failure is in the sproc. At least that's how I've dealt with it in the past. Another is to treat the sproc as the end point and the calling end point as the testing harness... so the sproc does nothing initially and returns a clean run... then as you build hte sproc, you continually run the tests, and if it fails, then you know the last thing added/changed is the failure point.Quote:
Originally Posted by FunkyDexter
What I like about it is the speed at which we can deploy something... push out the assemblies, load the specs into the database, and it's there. Occasionally we run into issues with browsers caching things, but it usually happens in the development cycle when the change rate is high.Quote:
Originally Posted by FunkyDexter
It can be a lot of fun to work in, and infuriating at the same time. There are few things I'd like to see done differently. But over all, it's quite the system.
This is a myth. I spent 8 semesters getting my Bachelor's in "Computer Science and Engineering" and even though I took a 3-hour "Software Engineering" course, it was really a slightly more software-focused "Project Management" course. We talked about estimation, we talked about waterfall, we talked about testing, but we did not implement a single line of code in that class. Every bit of "proper" practices I know has come from either reading a book, reading blogs/social media, or writing terrible code then begging people to help me improve it. I don't know anyone else that learned much about coding style in college either. Unless things have changed dramatically, it's still something you are expected to either self-train or get on the job.Quote:
All these proper (sic) coding techniques generally come from a formalized education.
I really don't like the rest of your post, either. I feel like you use "VB6 developer" as a derogatory term. You mean "Mort". Mort is distinctly Microsoft, because Microsoft's sales pitch is "Programming is easy, you don't need any kind of training to be a programmer." That is false, and damaging to Mort.
For a whole class of relatively trivial application, Mort's the best fit. No one wants to pay my wage for a single-screen CRUD app. My degree of architecture is overkill for it. But invariably, because it's non-technical bosses that need Mort most, eventually the needs of the application outgrow the "no-architecture zone". That the whole of Windows training materials treats architecture as "for nerds" means Mort is completely unprepared to recognize this.
Mort doesn't have a problem and ask questions like, "What patterns exist for sharing data between multiple forms?" and spend a few days prototyping approaches. Mort asks, "How do I make Form1.Button2_Click() get data from Form3.TextBox4?" and uses the first answer that can be pasted into his solution. This works in perpetuity because Mort works alone, doesn't have code reviews, and often his boss can only use "does the software work" as a measure of success.
This excerpt from a beginning Python text lays out disciplined rules for writing If..Then statements. In Windows books, this advice isn't present in any of the 15+ texts I read. It's stashed away in "Code Complete", the "just for architects" book I ignored for 4 years. It could've saved me dozens of hours over those years, but the Windows productivity myth had me believe that kind of thinking was for PMs, not developers.
The problem isn't VB6. The problem is that Windows has to sell itself, and to do so it has to put VB6 in skimpy outfits and ask it to do questionable things. You don't see as prevalent a Mort community in other languages because they don't pretend programming is easy, they integrate basic architectural thinking into their tutorials. We, as a community entity, can't reverse this so long as the "official" materials distributed by MS and their evangelists perpetuate the "You don't need to think to program" myth.
Most people don't read architecture books or specialized architecture blogs. They only learn proper practices if tutorial materials and community examples advocate those practices. When even the language designer favors quick fixes and results-oriented thinking, there's almost no hope. I didn't get any of my respect for architecture until I branched out into other, non-.NET languages.
So I really, really, really think the next VB6 won't be a VB and won't come from MS. It's probably already present, being used productively by tons of new developers. But we don't recognize it, because what we tend to mean by "new VB6" is "a happy toolkit for making turnkey applications with wizards", and that isn't exciting to anyone for very long.
I see this as far more of a .Net issue than a VB6 issue. The bar to entry is far lower via the Express and now Community Editions for one thing (free vs. paid-for tools), and more people attempt this now than in the heyday of VB6.
I'm amazed we see as much VB6 "traffic" in help forums as we do for those reasons. I can only chalk that up to people who got comfortable in Office VBA and persisted until they somehow got their hands on VB6, and more and more often probably the pirated "Portable Edition" floating around warez sites.
But the proof of my premise is in the forums: VB.Net and C# forums seems to contain just as much Mortitude as anywhere else. You only see a higher proportion in web scripting forums.
That's been my most commonly used technique although sometimes I only partially apply it:DQuote:
writing terrible code then begging people to help me improve it
I agree with a lot of the rest of what you've said but I don't think I'd limit it to a criticism of VB6. I see them same in VB.Net and I've definitely seen it in the web development community as well. I used to work with a bunch of data scientists who used Python to query their models and I saw it there too. Come to think of it I think I've seen it to a greater or lesser extent in every language I've worked in. It shouldn't be surprising as "make it work" is the job these people are paid to do. "Design me an architecture" is not. I don't condemn that sort of thinking - it's pragmatic. It doesn't particularly turn me on but I don't condemn it. In fact, it has served me well on many of the projects I've worked on.
In fact, I think this may be one of the cruxes of the 6 vs .Net debate. 6 was only ever intended to serve that kind of quick and dirty approach and it does so with aplomb. The fact that someone with enough skill can take it further is great but it tends to require them to use hacks and techniques the designers never intended or to compromise on the design. .Net was intended to support a more engineered approach from the start. How well MS succeeded in delivering on that intention is subjective and I'm sure we can debate it until the cows come home but the existence of the intention should be undeniable.
I can't remember the members name but we had someone who weighed into these debates and their entire argument distilled to ".Net users are to stupid to use 6, you've got to be a genius to use it". That always struck me as a really stupid argument because the whole point of a language is to make your life easier, not harder.
edit> looks like Dil and I crossed over and said... almost exactly the same things. Guess it's time to book that snowboarding trip to Hades.:wave:
What I find always happens in a discussion of Morts is we act like there's only one kind of programmer, and one kind of job. The reality is there's a whole range of programmers, much like a range of plumbers. Some plumbers are licensed, bonded, only take on big contracting jobs, and have a reputation for doing lifetime work. Others are licensed, bonded, and do the best they can to fit your budget with quality work. Some are licensed, bonded scam artists that will cut any corner they can while staying "legal". Some are just your buddy with a set of tools.
Now, there's a problem. You hire a plumber because you are not a plumber. So especially when you are considering a big job, you may not understand why one plumber's estimate is so much more expensive than another's. There's lots of materials and practices involved, maybe the more expensive plumber works to provide "lifetime" work while the cheaper one works for "good enough". When you don't know what either of these mean, all you know is one looks silly expensive for what you feel is a small job.
This is exactly like programmers and projects! In every language, you have people of every skill level from "proven guru" to "wrote some hello worlds". They often demand wages and compensation in line with their skills, though the people in the middle are fraught with peril and risk. But our projects also vary wildly in complexity.
Mort's a great fit for projects that don't have a lot of complexity. Mort is cheap and gets the job done. When you've got a leaky sink, you find a friend with a pipe wrench and offer a beer. It turns out there's a lot of people that meet the criteria "has a wrench and wants a beer".
Mort can struggle his way through projects with medium complexity. It's hard to say what "medium" complexity is without being a developer yourself. But multiple screens and functions in one application tends to do the trick. Here, a more experienced developer can be dubious vs. Mort: an experienced Mort might be neck and neck. I think this is the segment of programming where most bad decisions are made, because it's almost impossible to tell if you're choosing the right person for the job.
Mort's hopelessly lost on very complex projects, like a high-reliability banking system. They require specialized knowledge and a knack for managing complexity that only comes with experience. There's maybe a few dozen people in any market that can write this at all.
So when we talk about "VB6 being a toy language" or "VB .NET dumbing things down", we're often looking at a scenario where someone asked Mort to do a job he was unqualified for. That's not the wrench's fault, that's the project manager's fault. But sometimes, the project manager's just some random business owner that knows she needs a programmer, but doesn't understand anything at all about it. She doesn't know how to find a good programmer, and has to go through random ads or shady recruiters. What she ends up with is a poor fit for a poorly defined project that any seasoned developer would recognize. She thinks she has a leaky sink and hires a cheap, unlicensed plumber, but in reality has corroded pipes that need to be replaced. The plumber doesn't recognize the real problem, and months later her pipes burst, causing tons of damage.
And what do we do? We chuckle and say, "That's what you get for hiring a plumber that doesn't use this brand of pipe wrench."
I'm imagining a Mort plumber, desperately trying to fix pipes that are spraying water everywhere and have been for four hours. Water's pooled in the room, and everything's waterlogged. The plumber's screaming "IT'S FINE! THIS IS UNDER CONTROL!" The homeowner looks on, nodding their head. "Wow, this is messier than I thought. I'm glad I hired a plumber."
Programming is the only reality where this happens! And we laugh and sneer at the people involved. That makes me hurt a little.
There is much wisdom in these words.Quote:
So when we talk about "VB6 being a toy language" or "VB .NET dumbing things down", we're often looking at a scenario where someone asked Mort to do a job he was unqualified for.
Of course it is, you are right. However the VB/VB.NET eliminates the arguments between languages with complete dissimilar roles.Quote:
Originally Posted by dilettante
And yes, the barrier to entry is very low. That's why we have crap software because anyone with an internet connection can see themselves as a programmer. I'll say it again, without a formal education, one is going to be seriously laking in skill and capability. Yeah, some people don't like it, but then people are more 'sensitive' to the truth when it doesn't fit their world view. The world smacks them down, and they complain there are no jobs for skilled workers, not realizing they don't have skills worth paying for.
If there were formal training that made a good developer, we'd have a licensing process much like plumbers and electricians have. I'm very, very confused what formal training you think exists that produces good developers, SJWhiteley. I've never heard of such a thing, nor have any of my coworkers or our recruiters.
My 4-year degree taught me the plumbing equivalent of "being able to use a faucet and identify its parts". Learning to disassemble it, diagnose problems, and fashion faucets out of thin air came from reading books no one told me to read.
If you pointed this out to them, would they be Mortified?Quote:
Originally Posted by dilettante
From what I have seen of research into the field of development there is no solid way to ensure that you are finding good programmers other than finding programmers who have done good work. No badge, diploma, or certification appears to have any particular merit.
The above sentence needs a correction (again):Quote:
Originally Posted by FunkyDexter
VB6 was never intended to serve *only* the quick and dirty approach - but it does so with aplomb.
VB6 has everything what's needed, to write well engineered Apps in a clean way - to workQuote:
Originally Posted by FunkyDexter
like that requires just about the same "skill level" which is common also in other languages,
and that has nothing to do with "taking it further than it was desigend for" - e.g. COMponent-
services which allowed transactions were introduced into .NET very late - and were then
based on the very same COM-backbone which served VB6 for years already.
No Hacks I'm aware about are needed, to write well-engineered and complex Apps in VB6.
Wondering when it will sink in, that it is never about the tool - it's just Developers -
their experience and skill-level which decides about software-quality.
And I can only repeat that the only way to do a decent comparison among software-tools which play
in the same ballpark, is to compare Notes after producing a *concrete-solution-for-the-same thing* -
that's after all what software-tools were built for, - anything else is just "speculating around".
Olaf
That would be a really interesting test to be able to run. The problem would have to be non-trivial, and the skill levels of the developers would have to be roughly equivalent in the different languages, which makes the test likely to be impossible, but it sure would be interesting to a lot of people.Quote:
Originally Posted by Schmidt
Ack, that's the spirit.Quote:
Originally Posted by Shaggy Hiker
And another thing I'd like to mention as "food for thought" ...
I guess 90% of our work (especially in LOB-Apps) is quite uninteresting
and for the most part "just boring" (always the same simple DataEntry-
Processing- and Persistence cycles which are "as time goes by" just re-worded
and re-taught in ever new paradigms - the discussion in the recent postings
deriled into "DB-based GUIs" - a thing which an old and experienced Access,
FoxPro, Clipper, VO (put your 4GL-lang here ... 'PowerBuilder' anyone?) - guy has
already done (just not using as many fancy words to describe it) for decades.
That said, what I found though is, that a lot of these large and boring Apps were written
by developers with, say - "average skills". I don't mean that condescending at all -
I would even go that far, that I suspect that these Apps were *requiring* a special
mindset, to "rifle through those boring problems with insistence" - a thing which is
missing in many of the "artist-developers" (who lose interest and "their bite" as soon
as "the challenging things in a problem were recognized and solved").
There's "sprinters" and "long-runners" - the latter type often being the better
entrepeneurs (Mort or not, well-designed App or not - these are the guys who
will "produce" - and enhance+maintain with endurance and tenacity).
Olaf
I've already put some thoughts (as well as quite some work) into that in my post #730:Quote:
Originally Posted by Shaggy Hiker
http://www.vbforums.com/showthread.p...=1#post4917477
This is, as I think a nice mix of DB-related (search)stuff, networking-stuff, threading-stuff -
text-parsing is involved - and a little GUI-challenge is in there as well, all of them things
we use in our daily work as (mainly) LOB-developers.
It's still doable in a managable (teams allowed) amount of time I think - and a few additional
challenges could be added as well (with regards to engineering, which almost always touches
the realm of easy extensibility...
E.g. one could require in addition, that the App should be already designed in a way, to allow
easy movement of the Server-part to a WebServer - and the GUI-Part into a Browser (as a
kind of "customer-change-request").
Would like to see solutions in other languages as well (e.g. a Javascript, or Python-solution) -
not only .NET or VB6 as the contenders - a Forum for that is already there - and when it's
indeed well-engineered solutions which come out in the end - we could make that even a
sticky-thread in the contest-forum, kept alive to allow other interested devs to provide
better designed or optimized solutions over time - and stick them in there.
Olaf
To my clients my skills are being able to sit through long meetings about why we won't cover transplant surgeries or how we want to change the pension plan year to calendar (from Oct-Sep) and "what exactly do you do with those 3 months" and turn those meetings into deliverables that are an exact match.
The fact that I am bored is why I created my own 4GL for delivery of those solutions.
And all the while I use those funds to finance a startup doing natural language processing - wrote my own REGEX - all in C++. I've got a patent on a database concept to go with all this. The boring front end to all that is a document management system.