• Welcome to the new Internet Infidels Discussion Board, formerly Talk Freethought.

The Programming Thread

First there was spaghetti code, then there was structured programming, then came object oriented programming to eal with large scale multi programmer systems.Any C++ OOP people? Is there a coding school of thoutht you use or do you just have itt it?

Productivity remorse? That is a new one. I always took away a good feeling being productive. I learned early on that productivity paid higher, but more important was the more productive and independent you were the more freedom you had.
Productivity means fewer people get paid. I'm working on the mother of all VBA assisted spreadsheets to make the work of 10 people full time, possible for 2.
 
Wading back into Java for the first time in about.. 2 years?

ihnmotp.jpg


Thinking.. what the hell is all of this crap!?
 
First there was spaghetti code, then there was structured programming, then came object oriented programming to eal with large scale multi programmer systems.Any C++ OOP people? Is there a coding school of thoutht you use or do you just have itt it?

Productivity remorse? That is a new one. I always took away a good feeling being productive. I learned early on that productivity paid higher, but more important was the more productive and independent you were the more freedom you had.
Productivity means fewer people get paid. I'm working on the mother of all VBA assisted spreadsheets to make the work of 10 people full time, possible for 2.



The MS Office suite itself eliminated what were good paying semi skilled jobs and skilled jobs.

In the 90s I inhered a spreadsheet that grew over time uncontrolled and unstructured. A mess that should have been done in in Pascal or Basic even.
 
Wrote one of the most complicated algorithms in my career yesterday (all the while feeling like garbage which made it more of a miracle). I was going to try to reproduce the code here but it would probably make no sense out of context. But the problem went something like this:

Code:
1 Query all blood sample records for every patient encounter in the hospital
2 Only pull records from each patient's most recent encounter
3 If that encounter's set of records includes a record of type 1, with field A populated
	- Print the most recent record of that type
	- Don't print the other records in the set
4 If that set of records includes a record of type 1, without field A populated
	- and that set of records has no records of type 1 with field A populated
	- and that set of records contains a record of type 2
	- Print the record of type 1 and 2

Took me a little longer than usual to wrap my head around it. The tricky part is that it needed nested loops, and on point 4 it needed two nested loops within a loop, which was also contingent on point 3 already being dealt with.

Originally I attempted to flag every single record with an is_this_printed_flag, but later switched to flagging types of encounter. First I identified encounters from point 3 as type 1, and then encounters from point 4 as type 2 (any others defaulted to 0). Then when I went to print, as the records were displayed in the correct order and sorted by person, I looked for specific encounter/record types and broke the loop when the correct rows were found.

Still not 100% sure I've got it right, but that is a problem with specification, which is a bit confusing too.

It may not look extremely hard, but most of the time I'm querying and manipulating data, or issuing Google searches. Usually I don't actually have to think this much.
 
Twice today some asshole has blamed me, or my product, for their own fuck up.
My favorite thing is getting a call, "There is something wrong with the log".

No, there likely isn't something wrong, because we would have noticed it 10 years ago!
 
Wrote one of the most complicated algorithms in my career yesterday (all the while feeling like garbage which made it more of a miracle). I was going to try to reproduce the code here but it would probably make no sense out of context. But the problem went something like this:

Code:
1 Query all blood sample records for every patient encounter in the hospital
2 Only pull records from each patient's most recent encounter
3 If that encounter's set of records includes a record of type 1, with field A populated
	- Print the most recent record of that type
	- Don't print the other records in the set
4 If that set of records includes a record of type 1, without field A populated
	- and that set of records has no records of type 1 with field A populated
	- and that set of records contains a record of type 2
	- Print the record of type 1 and 2

Took me a little longer than usual to wrap my head around it. The tricky part is that it needed nested loops, and on point 4 it needed two nested loops within a loop, which was also contingent on point 3 already being dealt with.

Originally I attempted to flag every single record with an is_this_printed_flag, but later switched to flagging types of encounter. First I identified encounters from point 3 as type 1, and then encounters from point 4 as type 2 (any others defaulted to 0). Then when I went to print, as the records were displayed in the correct order and sorted by person, I looked for specific encounter/record types and broke the loop when the correct rows were found.

Still not 100% sure I've got it right, but that is a problem with specification, which is a bit confusing too.

It may not look extremely hard, but most of the time I'm querying and manipulating data, or issuing Google searches. Usually I don't actually have to think this much.

Sounds like a pain if you have to do it in SQL. No big deal if you can pull in all records identified in #2.
 
Wrote one of the most complicated algorithms in my career yesterday (all the while feeling like garbage which made it more of a miracle). I was going to try to reproduce the code here but it would probably make no sense out of context. But the problem went something like this:

Code:
1 Query all blood sample records for every patient encounter in the hospital
2 Only pull records from each patient's most recent encounter
3 If that encounter's set of records includes a record of type 1, with field A populated
	- Print the most recent record of that type
	- Don't print the other records in the set
4 If that set of records includes a record of type 1, without field A populated
	- and that set of records has no records of type 1 with field A populated
	- and that set of records contains a record of type 2
	- Print the record of type 1 and 2

Took me a little longer than usual to wrap my head around it. The tricky part is that it needed nested loops, and on point 4 it needed two nested loops within a loop, which was also contingent on point 3 already being dealt with.

Originally I attempted to flag every single record with an is_this_printed_flag, but later switched to flagging types of encounter. First I identified encounters from point 3 as type 1, and then encounters from point 4 as type 2 (any others defaulted to 0). Then when I went to print, as the records were displayed in the correct order and sorted by person, I looked for specific encounter/record types and broke the loop when the correct rows were found.

Still not 100% sure I've got it right, but that is a problem with specification, which is a bit confusing too.

It may not look extremely hard, but most of the time I'm querying and manipulating data, or issuing Google searches. Usually I don't actually have to think this much.

Sounds like a pain if you have to do it in SQL. No big deal if you can pull in all records identified in #2.

Yea, after a few stumbles I got it in decent time, but I must be out of practice because I hadn't written anything like that in a while.

The overwhelming majority of algorithms I've written in ~ 5 years? Were all simpler than this one. Most of the code I've written that I would call hard were just features I'd never written before and had to seek out a design.
 
Wrote one of the most complicated algorithms in my career yesterday (all the while feeling like garbage which made it more of a miracle). I was going to try to reproduce the code here but it would probably make no sense out of context. But the problem went something like this:

Code:
1 Query all blood sample records for every patient encounter in the hospital
2 Only pull records from each patient's most recent encounter
3 If that encounter's set of records includes a record of type 1, with field A populated
	- Print the most recent record of that type
	- Don't print the other records in the set
4 If that set of records includes a record of type 1, without field A populated
	- and that set of records has no records of type 1 with field A populated
	- and that set of records contains a record of type 2
	- Print the record of type 1 and 2

Took me a little longer than usual to wrap my head around it. The tricky part is that it needed nested loops, and on point 4 it needed two nested loops within a loop, which was also contingent on point 3 already being dealt with.

Originally I attempted to flag every single record with an is_this_printed_flag, but later switched to flagging types of encounter. First I identified encounters from point 3 as type 1, and then encounters from point 4 as type 2 (any others defaulted to 0). Then when I went to print, as the records were displayed in the correct order and sorted by person, I looked for specific encounter/record types and broke the loop when the correct rows were found.

Still not 100% sure I've got it right, but that is a problem with specification, which is a bit confusing too.

It may not look extremely hard, but most of the time I'm querying and manipulating data, or issuing Google searches. Usually I don't actually have to think this much.

Steps 1 and 2 are something I deal with all the time and I've yet to find an efficient way to do it in SQL. So I first query for the "most recent date (as your example is doing)". I can then query again using the extra criteria, most recent date, from the previous query to get the single record per "patient".
 
Wrote one of the most complicated algorithms in my career yesterday (all the while feeling like garbage which made it more of a miracle). I was going to try to reproduce the code here but it would probably make no sense out of context. But the problem went something like this:

Code:
1 Query all blood sample records for every patient encounter in the hospital
2 Only pull records from each patient's most recent encounter
3 If that encounter's set of records includes a record of type 1, with field A populated
	- Print the most recent record of that type
	- Don't print the other records in the set
4 If that set of records includes a record of type 1, without field A populated
	- and that set of records has no records of type 1 with field A populated
	- and that set of records contains a record of type 2
	- Print the record of type 1 and 2

Took me a little longer than usual to wrap my head around it. The tricky part is that it needed nested loops, and on point 4 it needed two nested loops within a loop, which was also contingent on point 3 already being dealt with.

Originally I attempted to flag every single record with an is_this_printed_flag, but later switched to flagging types of encounter. First I identified encounters from point 3 as type 1, and then encounters from point 4 as type 2 (any others defaulted to 0). Then when I went to print, as the records were displayed in the correct order and sorted by person, I looked for specific encounter/record types and broke the loop when the correct rows were found.

Still not 100% sure I've got it right, but that is a problem with specification, which is a bit confusing too.

It may not look extremely hard, but most of the time I'm querying and manipulating data, or issuing Google searches. Usually I don't actually have to think this much.

Steps 1 and 2 are something I deal with all the time and I've yet to find an efficient way to do it in SQL. So I first query for the "most recent date (as your example is doing)". I can then query again using the extra criteria, most recent date, from the previous query to get the single record per "patient".

I was doing it in Cerner CCL, which is a kind of less robust SQL used for reporting (not even sure of the technical term for this type of language). My algorithm for steps 1 and 2 went something like this:

Code:
SELECT
    RECORDS IN ALL ENCOUNTERS
ORDER BY ENCOUNTER etc
HEAD PERSON_ID (group by person id)
    FIRST_ENC_ID = 0.0
DETAIL (all records for person)
    IF(FIRST_ENC_ID = 0.0)
        FIRST_ENC_ID = ENCOUNTER.ENCNTR_ID
    ENDIF

    IF(ENCOUNTER.ENCNTR_ID = FIRST_ENC_ID)
        STORE RECORD
    ENDIF

God I don't even flinch when I write my if statements like that anymore.

The problem with the last two points is that I had to know what was going on in all the records for a given encounter before I could isolate the record I wanted. No way to do that with a query so I had to parse the data.
 
And in today's fun I'm updating a label printout. The fun part is that Cerner hasn't developed a way to debug this virtually so I have to issue a print every time I make an update, which involves walking about 50 meters to the printer. I also have to cycle some servers with each update, which takes about 45 minutes to process each time.

I imagine this is similar to what programmers in the 70s and 80s felt like.
 
And in today's fun I'm updating a label printout. The fun part is that Cerner hasn't developed a way to debug this virtually so I have to issue a print every time I make an update, which involves walking about 50 meters to the printer. I also have to cycle some servers with each update, which takes about 45 minutes to process each time.

I imagine this is similar to what programmers in the 70s and 80s felt like.

90+% of my "printouts" go to a .PDF or .XPS document printer.
 
And in today's fun I'm updating a label printout. The fun part is that Cerner hasn't developed a way to debug this virtually so I have to issue a print every time I make an update, which involves walking about 50 meters to the printer. I also have to cycle some servers with each update, which takes about 45 minutes to process each time.

I imagine this is similar to what programmers in the 70s and 80s felt like.

90+% of my "printouts" go to a .PDF or .XPS document printer.

Unfortunately I can only issue the print from a Cerner app to a label printer. Normal rules do not apply.
 
And in today's fun I'm updating a label printout. The fun part is that Cerner hasn't developed a way to debug this virtually so I have to issue a print every time I make an update, which involves walking about 50 meters to the printer. I also have to cycle some servers with each update, which takes about 45 minutes to process each time.

I imagine this is similar to what programmers in the 70s and 80s felt like.

90+% of my "printouts" go to a .PDF or .XPS document printer.

Unfortunately I can only issue the print from a Cerner app to a label printer. Normal rules do not apply.

Yeah, labels. Most of my printouts that don't go to one of the electronic forms are going to a label printer. (Admittedly, often I need the labels because they contain bar codes and what I'm actually working on is the code that uses those bar codes.) Actually, for the most part I cheated with my label code--the user uses the manufacturer's label-printing program to build the label except instead of actual values they do things like %jobname%. Then they print it to a file and I use that file as a template, replacing the codes with the actual values. The guy actually using the labels sometimes has to run off several test labels to get the layout right (while everything will appear exactly where it's commanded the length changes which can cause things to overlap that didn't in the designer.)
 
So it's been nearly three years and all I've learned is a largely irrelevant technology. And with our wedding / honeymoon last year done and over with, and a bit of a lull where I don't have much on the go, I'm planning on sharpening the saw a bit.

Last year I spent a few hours getting familiar with React, but over the next number of months I'd like to dive a bit deeper into it, as well as Vue, and maybe even Node but solely out of curiosity. Moreover, I mostly want to get some significant code up to my Github account as a visual indicator that I can learn. The last major push I made to my account was a bunch of college projects in 2014, and since then I've only tinkered around a tiny bit here and there.

Having worked for a fortune 500 company since then certainly doesn't hurt, but in my current role it doesn't look like I'm doing much.
 
Last year I spent a few hours getting familiar with React, but over the next number of months I'd like to dive a bit deeper into it, as well as Vue, and maybe even Node but solely out of curiosity.

The hardest part of JavaScript development is tooling up an IDE and configuring an environment. It is a colossal headfuck.

Writing the actual code is quite pleasant.
 
Last year I spent a few hours getting familiar with React, but over the next number of months I'd like to dive a bit deeper into it, as well as Vue, and maybe even Node but solely out of curiosity.

The hardest part of JavaScript development is tooling up an IDE and configuring an environment. It is a colossal headfuck.

Writing the actual code is quite pleasant.

That was also my experience last year.

- Think I'll quickly fuck around with React
*wait, wtf..? Guess I need a whole afternoon to do this*

Eventually I had to set a day aside, and it was a tutorial that helped me through set up.
 
Last year I spent a few hours getting familiar with React, but over the next number of months I'd like to dive a bit deeper into it, as well as Vue, and maybe even Node but solely out of curiosity.

The hardest part of JavaScript development is tooling up an IDE and configuring an environment. It is a colossal headfuck.

Writing the actual code is quite pleasant.

That was also my experience last year.

- Think I'll quickly fuck around with React
*wait, wtf..? Guess I need a whole afternoon to do this*

Eventually I had to set a day aside, and it was a tutorial that helped me through set up.

IDE's can certainly be a pain, but as far as jumping in and learning the basics of React a vanilla installation of VS Code should do just fine. From there, you just need to install NPM, and then run create-react-app to get to a good place to start playing with it. It really shouldn't take more than 5 or 10 minutes to get it up and running.
 
That was also my experience last year.

- Think I'll quickly fuck around with React
*wait, wtf..? Guess I need a whole afternoon to do this*

Eventually I had to set a day aside, and it was a tutorial that helped me through set up.

IDE's can certainly be a pain, but as far as jumping in and learning the basics of React a vanilla installation of VS Code should do just fine. From there, you just need to install NPM, and then run create-react-app to get to a good place to start playing with it. It really shouldn't take more than 5 or 10 minutes to get it up and running.

Indeed, the brunt of the effort I took last year was just figuring the bolded out. It didn't take long, but I actually had to engage my brain, rather than just opening up Sublime and starting to write.
 
That was also my experience last year.

- Think I'll quickly fuck around with React
*wait, wtf..? Guess I need a whole afternoon to do this*

Eventually I had to set a day aside, and it was a tutorial that helped me through set up.

IDE's can certainly be a pain, but as far as jumping in and learning the basics of React a vanilla installation of VS Code should do just fine. From there, you just need to install NPM, and then run create-react-app to get to a good place to start playing with it. It really shouldn't take more than 5 or 10 minutes to get it up and running.

Indeed, the brunt of the effort I took last year was just figuring the bolded out. It didn't take long, but I actually had to engage my brain, rather than just opening up Sublime and starting to write.

True enough, knowing that create-react-app will save you boatloads of time, and knowing that you need NPM to run create-react-app is an essential first step that most people don't realize when starting out. I took a 4 day bootcamp course from Tyler McGinnis (he has some great courses, BTW) when I first learned React, so that was 8 hours total, but it walked you through setting up React by hand in the first two hours.
 
Back
Top Bottom