Programming

[andrewducker]

Well, the subject line has probably gotten rid of most of you, and this next line will almost certainly get rid of the rest.

I'm learning C#.

Right, now I've got this journal to myself (and boy, does it feel spacious without anyone else here), I'll explain why (to myself, obviously).

I've been meaning to get back into programming again, but the little bits of dabbling I've done have largely been hampered by the fact that I've not really had any projects I've been that interested in. Not only that, but I'm very, very bored of doing low level work - writing yet another bit of code to deal with files, or fiddling about with endless calls to do the simplest interaction with the outside world just doesn't interest me any more.

Also, having been programming in COBOL for the last 9 months, and having always been envious of the Visual Studio IDE when I was working in VFP (it's a fantastic IDE and does all sorts of things that are just smooooth), I thought I should work with something in that.

I can't be arsed doing garbage collection, and I wanted something that would allow me to easily write/read web services. Which leaves C#, which (by sheer coincidence) has the nicest IDE of the entire of VS.NET.

I've been working my way through Visual Studio.NET Step by Step, which has so far been very good. I've only spent a few hours on it so far, and am about 40 pages in, but the power of the system is already very apparent. The fact that I can great a GUI interface by dragging and dropping a few textboxes onto a form, then go into the code behind the form, alter the position of the items in the code-based declaration and then go back to the screen to find it's automatically updated itself is something I would have killed for a few years ago.

The XML commenting system, the collapsible procedure view, the fact that the compiler messages are actually useful and the intellisense basically make this the best environment I've ever worked in. Erin's away for the weekend and I have to say I'm looking forward to spending most of it in front of the computer, typing away.

Comments

[thepaintedone.livejournal.com]

Not quite on your own :o)

I spend a lot of my working life doing Access apps which are heavily dependant on VBA and uses a very similar environment. All the little things sound silly, but stuff like auto-capitalisation of declared vaiables (easy to spot if you mis-type them) make a big difference to the grind of churning out code. I love coding in Access for much the same reasons you cite for C#. Its just so easy to knock together a simple and powerfull GUI based tool. Ok, the Jet engine sucks as a back end, but you can always code round it or just use another engine.

But then I sold my soul to the MS devil years ago.

[andrewducker]

Yeah. People talk a lot about how
"You can do it all with a text editor and a copy of gc"
but it's amazing how much more fun it is when you can say
"Here is my function, make it available over the web and then give me the declarations necessary to code the client."
and it just works.

And hurrah for multiple backends. When I did some simple stuff with MySQL on my hosted domain, the easiest way to get data out and analysed was to grab the ODBC driver, plug it into VFP and then do all the hard bits in there (I'm not as familliar with Access, by a long way).

[thepaintedone.livejournal.com]

Oddly enough Access is pretty good at data processing. On more than one occation I've linked into a SQl server to do a multi-table update query which cant be easily put together in SQL. Its big problem is locking, which is diabolical. Any more than a handfull of users in at once and it starts to creak at the edges. also if you use the built in data tool it has a nasty habit of leaving cursors open all over the database (very bad if you're talking to a SQL back end).

I've encountered a few of the 'I can do it anything in Vi' people and I generaly find them silly. I can walk to Edinburgh from London if I want to, but unless you're a masochist or have a really big point to prove its generaly more comfortable and quicker to use the train.

[kpollock.livejournal.com]

Example?? Cos I, with much experience in both, dispute that. Depends on your knowledge of actual SQL, really. I rarely use the graphical query construction tools in Access and never on SQL server. I suppose that I have been just used to doing SQL in text for WAY too long...

[thepaintedone.livejournal.com]

Maybe it depends what you grew up with. I didnt do the traditional DOS geekery before getting into IT. After my spectrum I went straight to Amigas and cut my teeth using a GUI. I find it more natural and intuitive than a command line.

I have to write a lot of SQL for the VB I use and appart from the simple stuff its nearly always quicker to generate the query in the QBE view (in either SQL server or Access) then cut and paste the underlying SQL into the code, rather than typing it all longhand. Less chance of typos and mistakes as well. Never mind remembering it all, its just quicker than all that typing. But then I've been building queries that way for many years now, so theres as much habit as logic to it.

[kpollock.livejournal.com]

SQL in code???? Yeauch! Bad practice in almost all cases (I'll [just] let you away with it if you have to to a search based on user input where what they can specify alters the columns/tables to search on and it;s multiple fields cos that's a pain and you don't really gain anything by sticking it in a stored proc).

I didn't do DOS either - VMS/UNIX at uni, mainframe cobol then VB (oracle/access/both kinds of SQL server, both MS and sybase) from 1994 on.

I find it just as quick to type SQL (and I can't type very well!). I'm not fond of enterprise manager for MS SQL Server (it's never been great in any version). I use the Query analyzser (ISQL-W replacement) as it has an object browser pane as well as the SQL text window.

Don't ask me about DTS (not if you want a polite answer anyway).

[thepaintedone.livejournal.com]

I know, although the particular systems I'm working on at the moment are all Access client to Access backend. Yes I can roll everything up in queries (which are roughly analagous to SP's), but its vastly easier, more stable and more reliable to drop it straight into the code.

But even using SP's you have to generate the text somewhere. when facing a four table query with different join types, 15 return fields and an aggregate somewhere. I can either spend 15 minutes labouriously typing it all out longhand, hoping i get all my punctuation right, or I can spend about 2 mins in the query builder and cut and paste the results. Usualy what I do is put together the bones of the query in the builder, then fine tune it in the text view. It just saves time.

I like Enterprise manager, but then I've been an Access coder since V2 so it appeals to my history. DTS can be a very powerfull tool, but it isnt the most intuitive of products.

I think VMS/Unix qualifies alongside DOS as a command line based entry into the industry :o)

[kpollock.livejournal.com]

Sounds a sensible approach (I ahve written Acces apps too and always ended up controlling everything from code to make it do what we needed), but do give the straight query analyzer a go unless you need to do DBA type stuff (where EM beats the pants off of tryign to recall which system sp does what you need).

DTs would be a very powerful tool if it worked properly. Try using it to import from multiple non-MS and MS database sources (some spreadsheets too) and then set it up as a scheduled job. Oh and the whole lot has to roll back if any one stage goes wrong. I did and infintely regretted not writing a VB app that could run as an NT scheduled program.

I mean it worked ( this is me we are talking about here :-) ) but occasionally took fits with talking to Oracle and wasn't reliable on the rollback front.

[thepaintedone.livejournal.com]

Access is a great and quite powerfull tool for knocking out quick and dirty systems. But inevitably you end up using less and less of the Jet engine and doing more and more in code so as to control things better. SQL server is a totaly different kettle of fish though. Never, ever under any circumstances let an Access front end loose on a SQL server using linked tables. Very nasty. I've deployed quite large Access-SQL solutions using pass through queries though.

SP's are a much better way of doing things. Assuming the coders know what they are doing. In my last company I inherited a bunch of SP's that formed a data mathcing engine. Being very busy I just assumed it worked and left them alone. Sadly they knew sweet FA about SQL server and treated the tables like big arrays in code. Lots of nested queries and cursors all over the place. Worked fine in all the demos and test system, but when the company actualy sold something and got 5 million records in the DB, suddenly it was taking 3 hours to run. Seeing as how this was supposed to be running real time on a webpage and the entire system locked up while it was running, this was very bad. A few index's and midnight coding sessions later though I got it down to about 8 seconds. Moral of the story, never assume your predecessor was competent!

With reagrds to DTS, I am a shamless MS whore, so I've never used it with other technology. I have encountered the all the way rollback thing though and it can drive you nuts, especialy as its often difficult to work out which field is causing the error.

[kpollock.livejournal.com]

I've always used passthroughs when I've been doing Access apps. I'd never put my data on an access db though choice and since you end up coding everything anyway, this means I'd never start an Access app (in fact haven't for a good few years and nobody has been trying to make me. Maintained a few.

And yes, never assume people are competent until they prove it. You should see the mess here cos some bright spark decided not to enforce any foreign keys. Indexes, yes (well there are now) but no referential integrity. makes is a pain in the backside to workou what teh relationships are!

[thepaintedone.livejournal.com]

Most of my DB career I've been dragging legacy Access systems kicking and screaming out of the 'Build your own CD database' level of competence (aka flat file hell). I'd dearly love to put a SQL back end into the five systems I have now, but the cash isnt there.

I have coded a couple of stand alone Access systems. The huge advantage of Access is how cheap it is. For the cost of a single Developer edition of Office you can deploy an Access app to as many people as you want, license free, using runtime deployment. This works out miles cheaper than a SQL solution. Provided you lay out the data well, and pay carefull attention to concurant users, it can do quite a good job as well. I'd still give my eye teeth for a SQL server though :o)

[kpollock.livejournal.com]

Been there, done that, deepest sympathy. Advice from the trenches - quote a month for SQL conversion and either do that or refuse.

Two words on cost: MSDN Subscription

Actually that doesn't help users (unless they have their own dev dept). Estimate maintenance costs for a year (@£550/day) and scare them.

[applause] thank you, thank you......

(apologies, still pissed from celebrating my birthday...)

[aberbotimue.livejournal.com]

so whats the project??

cos i have two for you

You said your self you have never wwanted more bandwidth since using waste, well, means it got your attention?? anyway, as we have seemn waste has a few issues.. so write one, that will recognise a file on many servers, like kazaa, but allows workgroup level sharing like waste, but with throttle ability, so the user can divert the bandwidth to the connected user they choos, not that the software chooses??

would get round the issues we had, and the issues I have with bandwidth, and would fix the issue guy and I had... sure I can think of more.. but I think the hrd bit will be stoping and starting downloads of a file and worse from many machines..

the other, is write the webserver side of the kensington game.. since i'm crap, and havn't started.. I realy want to write the AI bit, that communicates to the web server via a web service, since i need to try this web service thing out.

[aberbotimue.livejournal.com]

"something I would have killed for a few years ago."

HELLO

Delphi did that!

[kpollock.livejournal.com]

VB did 99% of that too.

I really should be doing C# (despite the fact that they have just started doing VB.Net here [not me, though, but peculiarly the dept head. I am not even going to speculate on that one). I know a fair bit about the internals of .net and the frame work but I can't find a book that is for experinced programmers. Well, Deitel&Deitel do one whcih Sean has, but 'experienced' to them appears not to mean experienced in Windows (or indeed even GUI programming of any sort)!

I so seriously need (from a CV point of view) to be doing .Net in my daily work. I will bring this up big style in my next rquarterly review.