« first day (1629 days earlier)      last day (1551 days later) » 

4:00 PM
.accdb as far as I saw is almost like mdb
 
There's Kexi, IIRC. Not sure it's a serious competitor. Alpha 5 probably comes closer but my biggest problem is that if you're looking at those, you're basically going to end up using Visual Studio.
 
What about Foxpro? </sarcasm>
 
Why use Alpha 5 (for instance) and write in their weird-ass XBasic that nobody else knows when you could be doing this in C#?
Ironically, Foxpro had more developer features than Access.
 
TBH, why use Access when you could be doing this in C#?
 
4:01 PM
Oh boy, Foxpro
 
The whole reason the business exists is because those applications were started by non-programmers solving a business problem.
 
Which is why Alpha 5 and its kind are fundamentally useless. Those non-programmers won't have access (pun intended) to those applications and can't install it
 
Because learning C# is expensive in terms of time, while building an Access DB is fast, efficient, and simple for small DBs
 
flaw: "VB is easy to learn" is BS
 
4:03 PM
Wut? Learning .NET languages is easy anymore compared to learning VBA.
 
I'm not talking VBA
 
people write VBA wrong all the time, just look at the ticker here :)
oh
 
Access, being a part of Office, means anyone can just start building some simple forms and let it grow organically (for better or worse) until it becomes a LoB and thus needs to be managed.
 
A programmer is expensive, and if people can build a DB without a programmer, they will
 
LoB?
 
4:03 PM
What it did right was provide a good steady hill from ground zero to summit.
 
@this then thrown into a shredder and rewritten from scratch as a CRUD app
 
VS in contrast requires you to climb a cliff to get on a plateau
 
Most simple stuff can be achieved without even knowing VBA exists, in Access
 
@MathieuGuindon that does happens sometime. Other times, it's too expensive to rewrite so it's instead extended and cleaned up in organic manner.
@Comintern Line of Business applications
 
@this Why? I don't see how an Access form is fundamentally different than a bound form in .NET.
 
4:05 PM
@Comintern Many people learned Visual Basic years ago and don't want to spend time learning C#, which is far less convenient for computer illiterate people
 
that's RD's audience
(I think)
 
Many people learned FORTRAN years ago too, but I wouldn't defend their continued use of it either.
 
@Comintern IIRC you have to deal with lot of components like datatable, dataadapter, etc., etc. The nonprogrammers only need to write a SQL query (using visual designer ugh) and they're done.
 
I agree, but many small businesses have Access Dbs that are at least a decade old, and they know how to """maintain""" it
 
@this and then you need to *gasp* .Dispose them!
 
4:06 PM
C# would require re-writing completely the DB's forms and logic, and would prevent the historical users from being able to maintain the application
 
They think they know how to maintain it.
 
Hence the quotes
But for most use cases, it's good enough
 
Trust me, the most egregious trash I work with at my day job are home rolled Access solutions.
 
I agree on that, as I have to maintain a particulary old and bad DB
But I think some users should be able to also work on it, because I can't be there all the time
Creating obfuscation by using C# will just give me a tremendous workload I can't afford to have because all the development will fall onto me
Having Access + VB, users can make their own small modifications if they need without having to go through me and waste my time
 
4:09 PM
At what cost though. Tech debt for Access looks like credit card debt.
 
"just add another global variable, it's good enough"
 
IOW, Access democratized the database application for those people. It might not be "pure", but it solves a business problem.
 
"it works, therefore it's good"
 
The users don't even know what variables are. They just create functions that are 4 lines long at best
 
Besides, you need to consider that nobody started out "I'll write me a LoB!"
 
4:10 PM
Right, but on the other hand, in practice it can create business problems.
 
it's usually "gee, I need some way to track my widgets. Ah, a single form will do it...."
 
You're seeing Access through the eyes of a real programmer that can afford wasting hours writing "good" code
 
and then add on other stuff. Emphasis on organic growth
which has good ROI for business.
 
You think real programmers waste time?
 
Access is often used when you don't have the luxury of wasting time writing code
 
4:11 PM
classic mistake
 
But this DB has been here for 10+ years and works
 
devs realized it, business will realize it eventually
 
Like it or not like, the business needs won't shirvel up and disappear just because it's not written in clean code.
 
If your data is essential to your business, you shouldn't treat it like some temp from Kelly Services.
 
4:12 PM
We have no developer in the company. many small companies can't afford a dev
 
Again, it doesn't start out that way.
 
You're just talking like every company has a dev dedicated to databases
 
Nobody has any idea if this or that Access database will be tomorrow's LoB.
 
I'm that guy. that's me. that's my entire career you're talking about.
 
The POS you got are successful databases that did some service to the businesses
 
4:13 PM
It's basically an aversion to short term cost v long term cost.
 
Yes, and that's the crux of our business.
 
Having a dev dedicated to DBs is quite a high long term cost for a small company
 
The ins. company I worked for had four full time employees that were basically responsible for checking data export errors from a crappy DB tool.
 
In other words, it's the old boot problem.
 
4:14 PM
A large cost with few savings
 
what I really really want to see one day is a system that lets non-programmer make business problem using clean code. Nobody has achieved that feat.
 
Buy a cardboard boot for $5 vs a leather one for $50.
The leather ones will outlast $100 of cardboard boots, but you have to have the money to get them.
 
@this no more difficult than writing an OS in VBA
3
 
IKR?
 
lol
 
4:15 PM
Most businesses will buy the cardboard ones.
Instead of going barefoot for a while and getting the leather ones later.
 
If you need to use them 1 time every decade, leather ones are overkill
And a waste of money
 
@Hosch250 The sad thing is that most businesses will keep buying the cardboard ones even after they've sunk the first couple thousand $.
 
The sadder thing is that some painted cardboard ones are marketed as genuine leather.
 
@Comintern and that's the job of good consultants to point that out.
 
So a business can think they are buying leather ones, and they get the cardboard look-alikes.
 
4:16 PM
@Hosch250 Wait, is that a PHP metaphor?
 
It could be.
Bad tech, bad programmer/DB person.
It's hard to do it right.
 
... and harder in PHP...
I should write an OS in PHP.
 
@Hosch250 that's almost a haiku!
 
@Comintern Already done.
> Formerly known as Xindesk, Cloudo is an open internet-based operating system that is written in PHP and runs the LAMP software bundle. It makes full use of the area of the browser and seamlessly integrates with the iPhone’s mobile browser. Written using open technologies, this browser based OS is high on features and usability. Currently in Public Beta, it opens to consumers next year.
 
......
 
4:19 PM
From 2009.
 
I had a VB6 gig a few years ago. a doors & windows manufacturer. they didn't care for "proper, clean code" - as long as it works, it's "good enough". "we make windows, not software". yet that shitty blob of fugly code (an add-in for the ERP system) was responsible for everything from pricing & promotions to reporting. Writing clean code was wasted time, refactoring was forbidden, the technical debt was astronomical.
 
@Hosch250 Oh lol
 
one day they started investigating the possibility of updating the ERP system
 
A few years ago? You've been with the suit place as long as I've known you, I thought.
> we make windows, not software
 
"We make windows, not software". Thought you were talking about MS there for a sec.
 
4:21 PM
@Hosch250 lol, remember when I was hyperactive on CR?
 
Windows is software, LOL.
 
I had to re-read that...
 
@MathieuGuindon Not really.
 
I'll have to reuse that joke someday :P
 
That was shortly before I got hyperactive.
 
4:22 PM
anyway the newer version could no longer be extended with a VB6 DLL
porting to .NET would have been a breeze if the code was anywhere near making sense
I'd have to check, but I'm pretty sure they're still on the old ERP
 
Last project like that I had, I actually did end up just re-writing the whole damned thing in c#.
 
So you jumped ship?
 
I would too.
 
I'd sneak some "special" compensation code into it and see how long it took for them to find out what I was really being paid.
 
4:23 PM
I'd do the same if C# allowed non programmers to easily add stuff to views and queries, and WPF/Forms was user friendly (and provided a proper "Dynamic Table" view that doesn't require a million lines of code)
 
no
non-programmers shouldn't be writing code
if you write code, learn to write code properly
 
I don't have the time to do everything they want
 
I'd put that another way. If you write code, you should act like a programmer.
 
Then jump ship and go to sensible employer.
If nobody works for the **** companies, they'll die.
 
My job isn't to write software, I'm a system engineer, not a DBA/programmer
 
4:25 PM
Similar to "if you wire your house, you should act like an electrician".
 
^
any idiot can wire a house
I know mine would catch fire within a month though
 
It's just as easy to burn the f'n place down with an Access application.
 
I'm curious about something. Does WPF or WinForms allow to have an OLE object embedded to act as a background ?
 
O_O
Why an OLE object?
 
like an Excel chart?
 
4:28 PM
Excel Sheets
 
Sure. You can put them in a WinForms control.
 
then pray
 
Which means you can wrap them for use by WPF
 
then pray again
 
Sounds like it will cause a mess
 
4:29 PM
Any OLE is a mess.
 
Unfortunately I have no alternative
 
What's your use case?
 
there's always an alternative
 
Having a A4 spreadsheet as the background, and Access fields over some of the "cells" so that users feel like they are filling the document, but they actually fill an Access table
 
4:30 PM
For example, grab its screen buffer and manually paint it as your background.
 
I could screenshot it and put it as a background, but it at least triple the time needed when I need to change something in the sheet
 
@Elcan So make Excel act like a database? I'd object on philosophical grounds.
 
^
 
I can't, the data needs to be integrated with other data that are in Access
Bidirectionally
 
GDI operations are probably much faster than OLE ones.
 
4:31 PM
i'm fine w/ reporting using Excel. But doing data entry?
 
There's no OLE operations. The object is just here in the background
never opened
 
why not at least split screen data entry/report view?
 
I have Access fields over the object so that users feel like they are using Excel
 
I can't even begin to count the number of times I've heard "we do it in Excel", or "it has to look just like you're in Excel", & the likes
 
Uh, then I guess I don't understand the "have an OLE object embedded" part.
 
4:32 PM
@MathieuGuindon you're not alone.
 
"tough luck, this is data entry, you get the screen you get, then you get used to it"
 
Access fields over an Excel sheet in an Access form
 
implicit in those "requirement" is "I want ability to change anything at will"
 
"it has to look just like you're in Excel" is just code for "I want to put crap where-ever the hell I feel like and you can sort it out".
 
4:33 PM
^
 
or what ComIntern said.
 
We have to follow our client's standard
And the users have been typing data in Excel sheets like that for years
 
@Elcan Just mock it up with controls if you have to.
 
I can't juste give them an Access table and tell them "Now figure out where the fields are"
 
Never give them a table.
 
4:35 PM
Access forms ftw.
 
^
 
That's why I give them an Ui similar to the documents they used for years and still use today
 
OK, here's the thing, though.... You're enabling their "paper form" mentality.
 
But they can print them and pass them around...
 
4:36 PM
Thing is, the client send us papers that look exactly like this and they have to type them
 
at least that's what I call it when I hear such requests.
 
And expect us to send back papers that look the same
 
Then write notes on them and scan them into emails.
 
make it a web form
 
You're just giving options that will overcomplicate maintenance
 
4:36 PM
Nope.
Higher initial development, but almost no maintenance when done right.
 
And you seem to think the users are computer litterate. They are not. They shouldn't waste time finding where to type stuff
 
If you have to maintain an existing system, someone did something wrong.
 
This has almost no maintenance either
Tell me what maintenance there is to what I did
 
@Elcan Wait, wut? Like replicating a freak'n Excel sheet in an Access form isn't maintenance?
 
How is it ? What maintenance is there to it that there wouldn't be with another solution ?
 
4:39 PM
what if - hypothetically - someone were to request another field to be added in the middle of that form?
 
I change the background Excel sheet with the new one, shift whatever fields need to be shifted down, and add the new field
5 minutes at worst
And these Excel sheets haven't changed in almost 20 years
The chemical industry, when it comes to standardized documents, isn't fast to change
 
vs add the new field if it's a web form, the layout adjusts itself.
 
But your form doesn't look like the document
So I need to have another workflow to generate a document that looks like this standard one
 
no, but I can make you a report that's laid out exactly like this
 
And I can print that form, looks exactly like a report
 
4:41 PM
except it's a data entry form
 
What happens when someone wants a read-only online version of the form?
 
they get a PDF version of the Excel sheet
 
I guess that works.
 
Wow. This whole thing seems like a freak'n COBOL form running on some old IBM big iron instead of an Access DB.
 
And, again, see the Excel background ? The client sends us hundreds of these in a PDF format that our guys have to type in Access
Manually
 
4:42 PM
Well, you are the one who handles this at the end of the day, but I'm not going to be applying for a position with your company.
 
They need the layout of the entry form to be identical to the sheet they have in front of them
 
That's exactly where the "paper form mentality" becomes a obstacle. They can't distinguish between the action of data entry and the action of reporting on it.
 
The real solution is to automate the data extraction from the PDFs...
 
@Elcan why not parse it automatically.
 
4:43 PM
^
 
because the PDF is an image
I wish it was as easy as parsing a PDF
 
not a showstopper. it's 2018
 
shouldn't stop a OCR software from doing that....
 
Because somebody scanned a physical document?
 
One of our clients uses a product just for that.
 
4:43 PM
Buy me a license then ;)
 
That's were the mentality feeds on itself.
 
not cheap, though. But it can be worth the business investment if you have lot of those documents
^^
 
surely less expensive than paying someone all year to type forms, then another one to verify no mistakes we made
 
These documents are all manually annotated by the client
 
If "everything is a paper document", people don't think twice about "here's a scan of the paper document"..
 
4:45 PM
Unless I can guess where they will annotate stuff, OCR can hardly understand what data the client wants to be changed
I wish we would have standardized data in a proper format to begin with, not scanned sheets of paper with red text written with a pen all over the sheet
 
TBH I'd probably keep the form in Excel, and write a macro that reads the worksheet and dumps the data into the Access table
 
data entry guy now just needs to click a button
 
We have no form in Excel
 
woopsie, don't need the data entry guy anymore
 
4:46 PM
And no data in Excel
 
7 mins ago, by Elcan
And these Excel sheets haven't changed in almost 20 years
I'm missing something
 
The blank sheets
 
So they print the Excel sheets, then fill out the hard copy?
Flashback to 1980.
 
They send us PDF prints of data they could send in Excel, yes
This is stupid, yes
 
4:48 PM
I bet the fields line up with typewriter carriage returns
 
I told my bosses and they don't care, I did my job
 
and writing proper code is wasted money!
 
At the end of the day, I get the same salary ;)
 
my point is that they see proper process as a huge expense, but refuse to see all the wasted money in their current process
 
But I fully 100% agree they are wasting time and money
 
4:50 PM
this is 100% solved with EDI
 
Or any number of other things.
Same as my insurance job - 4 people making $25K in perpetuity for something a $100K programmer solves in 3 months.
 
I work with the boundaries I have. Either we fire 4 people and do it properly, or I embed Excel sheets and put fields over them
That just becomes an ethical question
Are 4 people getting fired worth a faster workflow ?
 
SnapFish has 70% off sitewide. That means swag like a 20oz mug for $5.70.
 
Yep.
Because it could make or break the company down the road.
Then instead of 4 people, it's 100 people.
 
The company has been there for the past 20 years
 
4:53 PM
That's nothing.
 
Think of it this way. What productive work could those 4 people be doing.
 
And the time it's been around doesn't matter anyway.
 
Nothing, we already lack work
 
Finances and global market pressure change constantly.
@Elcan They could do productive work for someone else.
 
4:54 PM
It's not a company working at a multinational level in the US
We're working on less than a regional level in France
 
@Elcan Honest question. Is RD that difficult to understand? I've been cutting my teeth on C# with RD and while there's been a learning curve and frustration, it's not insurmountable.
Or are you referring to a specific issue? I'm still catching up on chat.
 
Not that difficult, but it's different from how I work in C# on my own projects, so it's hard to get into the mindset
 
@IvenBach Yes, there are certain parts that even I don't enjoy diving into.
 
Resolver and Parser are both ...
 
The "overuse" of Interfaces for example. (With quotes because I know they are useful, I just never use them)
 
4:56 PM
the IoC/DI can feel "magic" if you don't know where things are coming from
 
Partially because I don't know the requirements (resolver), and partially because it's just so blooming complicated with so many moving parts (resolver).
 
Mindset is understandable. I guess I just have the same sick twisted messed up kind of mind myself.
 
You see a function, think it's in the class, but no, it's in a parent parent parent class that uses an interface from another project
 
Abstraction at work.
 
you can't have 250K lines of code in a single mammoth project without any abstraction whatsoever. that would be unmaintainable.
 
4:58 PM
@IvenBach I find the resolver incredibly hard to follow when I'm not in a debugger.
 
I agree, it's just hard to figure out where stuff is, most of the time
 
CTRL-F12 helps alot.
 
And VS's "Find declaration" often require between 10 and 20 steps
 
because it can't go up to the source interface
 
4:58 PM
F12 is find declaration. CTRL-F12 is find implementation, or something like that.
 
try "go to implementation" instead
 
Resolver is in serious need of documentation, IMO
 
F12 in all its flavors is delicious.
 
And be glad it's not Roslyn. They have 60 projects to look through.
 
@this the whole damn project is
 
4:59 PM
I'm unglad I didn't discover the project sooner
 
Actually the resolver's documentation isn't that bad when it's non-obvious.
 
I might have been able to understand the source in less than a month
 
Granted you need MS-VBAL handy to look up the references...
 
@Comintern there's non-obivous parts of it?
 
@this MT = ??
 
5:00 PM
MultiThreading.
 
@Elcan you could always look at the source as it was 4 years ago :)
 
That would be the regex parser?
 
Somewhere in there :)
 
TBH, RD has a much cleaner code base than some of the crap I deal with at work.
 
5:01 PM
1.4.3 had a somewhat-broken grammar.
2.0 fixed dozens of edge cases.
 
pre-1.22 didn't even have a grammar
 
did it have a grampa?
 
The code is clean, it's just hard to figure out what some stuff does
 
@FreeMan Yeah. That old geezer didn't even use C#.
 
@Elcan You should look over the legacy indenter code then. :-D
 
5:07 PM
Ha!
 
@Comintern the moment I tried to decipher that code is when I lost my illusions and stopped deifying monuments like Stephen Bullen.
 
I'd lost my illusions long before that.
 
they're just humans with ideas, doing their best to implement them - just like us
 
Except Eric Lippert :P
 
5:08 PM
and Skeet
 
I bet both of them have written a bunch of hurried crap in their day.
 
But, seriously, some people have better ways to implement their ideas.
@Comintern And they've both admitted to it :)
 
If you can read through anything non-trivial that you've written and never think "WTF was I thinking there?", you're delusional.
 
or not learning anything new
 
5:10 PM
BTDT.
 
^^^
 
But, occasionally, I'll go through and still think "now that was done right."
 
Hell, sometimes I find myself thing "WTF am I doing here" when I'm writing it for the first time. Or "WTH kind of stupid corner did I get myself into here".
 
that does ring a bell cough self-closing pairs, autocompletion cough
 
I usually have my next refactoring planned by the time I'm about 75% through...
I'll consider myself a legend if I can get that down below like 25%.
 
5:12 PM
~whistles innocently
 
@Comintern Same.
 
like ... I'm the king of queuing large-scale refactorings and intermingling them during execution...
I've literally touched 20% of the codebase at work, and I'm not even 20% finished with the refactoring
then again I've dropped about 10% of the codebase, so there's that
 
I tend to spin off libraries with stuff I'm satisfied with.
 
I don't know if we could drop 10% of any of my projects, or RD.
But at work, heck, yes.
I'm somewhat frustrated, though, that they still insist on one project per logic.
One of their things is "it makes fewer projects to deploy". I'm like "MS Deploy does it automatically anyway..."
And when done right, it could make it so we could just swap the DLLs out without any downtime.
And only update one system at a time.
Oh, I told you I ordered a couple Manning books, right?
Well, it's been over 2 weeks, and they still haven't come. I email them about it, and guess what?
Their shipper went through a merger and their systems crashed, so they can't ship ATM :)
FYI, remind me if my company goes through a merger to jump ship.
Moving environments around is (going to be) bad enough.
 
5:32 PM
@Elcan That fills me with :sad:. I strive to put myself out of a job by automating.
In your opinion is it better:
1) Take to completion the initial plan. Then go back and refactor what you just finished.
2) Mid-flight start refactoring and combine them.
1 - strikes me as an atomic mindset of fully doing something, even when you know it'll get erased right away.
 
@IvenBach Depends on many things.
 
1 is tech debt acceptance
 
A) how much time you have.
 
@IvenBach Depends. If a light rework will make finishing it easier, do that. If not, just finish it and make a note somewhere.
 
Doesn't everything #Depend?
 
5:37 PM
B) how big the new changes are.
 
Most of the time, it's stuff that "has to be done now", so it gets fixed the next time I touch it.
 
Since we were discussing how things have been done and that's why we continue doing them
 
@IvenBach I do it a lot for my actual job as a system engineer
When you have to program 1000+ devices with 50+ parameters each, automation is required
 
Is your data input conundrum something you don't normally deal with then?
 
We work for a big factory, and each unit has a different way of being programmed
So each time we work for a new unit, we develop tools to work faster for that unit. The "programs" aren't text based. They are function blocks with parameters, some programs can go up to 200 parameters. We spend lots of time automating the import/export processes, but in the end it saves us days of work
 
5:54 PM
What type of factory?
Paint, chemicals, petroleum, textiles, etc..?
 
I spent 2 weeks writing a tool that allows us to work from the export files (that use a JSON like format, but not JSON so I had to write my own parser). This stuff still saves us time today because we don't need to import data to use it
Chemicals
 
What kind of chemicals? ChemEng is my undergrad field of study.
 
Lots of things. Chloromethanes, Latex, lots of stuff I don't even know
I only worked for 3 units. There's like 30 of them
They also produce Vinyl Chloride, Allyle Chloride...
 
How much has automation been a factor in productivity where you work?
 
Good question, luckily we replaced one of the oldest units a few months ago. Went from pneumatic panels manually tuned to a full distributed control system.
The plant's company didn't tell us how much it improved, but we know it was very successful
 
5:59 PM
What PLC systems do you use?
 
Not PLC, DCS. We used Emerson's DeltaV
 

« first day (1629 days earlier)      last day (1551 days later) »