IT/Software career thread: Invert binary trees for dollars.

chaos · Jan 29, 2020

I don't know shit about data science/bigdata/machine learning stuff. Learning SQL is never a bad idea, though.

Lendarios · Jan 29, 2020

Deebo said:
I've looked into some basic coding stuff before. I would love to learn it, but it seems daunting to me, and im not even sure where to start or whats going to be able to teach me coding efficiently without me getting overloaded with info.

If you want to pick up coding I can help with advise and exercise and stuff. If you commit to it, we can help you past the roadblocks so you can learn how to do it.

Noodleface · Jan 29, 2020

Kiki said:
Are you fixing Dellserv or whatever they have hopefully upgraded to now?

I write BIOS for the storage servers (poweredge bios technically)

Deebo · Jan 29, 2020

Lendarios said:
If you want to pick up coding I can help with advise and exercise and stuff. If you commit to it, we can help you past the roadblocks so you can learn how to do it.

I started the Learn SQL module on Codecademy. So far it seems pretty straight forward, its just something I would have to do for a while to remember all the commands.

I am all about fake it till you make it. I broke into IT with just an A+ cert as a contractor, my first gig was deploying Symantec encryption on thick client computers in hospitals. Yeah its pretty easy stuff, but I was intimidated coming in, I was working with people that had been doing IT for 10+ years or more that ended up losing their jobs from cuts and were getting work however they could.

Then I went into being a field service tech at one of the hospitals I was working at. The FS manager liked how I was interacting with people and they needed another tech so he asked about me and my recruiter offered it to me.

Then I got into more of the EHR application side of things and I am level 2 support over that now. I just learned shit as fast as I could and googled stuff I didn't know.

chaos · Jan 29, 2020

Don't worry about memorizing commands, that's what google is for. Focus on core concepts. How to structure a query, database structure, etc. Lend is for sure your better resource than me when it comes to coding, but I'd suggest once you're comfortable with sql on its own you look into using it programmatically, write a script to scrape some data from something like a website or whatever and put it in the database. It's less complicated than it seems.

TJT · Jan 30, 2020

Deebo said:
I started the Learn SQL module on Codecademy. So far it seems pretty straight forward, its just something I would have to do for a while to remember all the commands.

I am all about fake it till you make it. I broke into IT with just an A+ cert as a contractor, my first gig was deploying Symantec encryption on thick client computers in hospitals. Yeah its pretty easy stuff, but I was intimidated coming in, I was working with people that had been doing IT for 10+ years or more that ended up losing their jobs from cuts and were getting work however they could.

Then I went into being a field service tech at one of the hospitals I was working at. The FS manager liked how I was interacting with people and they needed another tech so he asked about me and my recruiter offered it to me.

Then I got into more of the EHR application side of things and I am level 2 support over that now. I just learned shit as fast as I could and googled stuff I didn't know.

If you've never done it. One of the best exercises to build these kind of skills is to make a full stack website. AWS free tier is very helpful for this. Make a dumb website with some minimal functionality and make a backend database for it from scratch. You'll use SQL, Python or whatever language you prefer, CSS or smth for the frontend and the AWS free tier EC2 linux server to deploy it. Then do the network shit for it so you can access it from the regular web.

Really isn't that daunting if you just do it piece by piece and is very helpful in understanding how it all works together.

Noodleface · Jan 30, 2020

Found another major bug in the code for 10+ years. We had code that logs errors to a DB, with a check on buffer size. If it's too big we throw it out - let's say up to 150 characters.

The code that calls this function makes a string up to 256 characters and sends it to previous mentioned function. I found a bunch of shit not being logged.

Changed logic to truncate instead of throw away.

Miracle

ShakyJake · Jan 30, 2020

I had a code review "argument" the other day which, honestly, I don't guess there's necessarily a right or wrong answer.

Here's the setup: you have an object that has a Process() method. This method is called frequently. Within this method you grab data from the database via a provider.

Which would you prefer:

Code:

class Foo {
    // ctor
    Foo() {
    {
 
    // process data
    void Process() {
        MyProvider provider = new MyProvider();
        MyData data = provider.getData();
        ...
    }
}

-or-

Code:

class Foo {
    private MyProvider _provider;
 
    //ctor
    Foo() {
        _provider = new MyProvider();
    }
 
    // process data
    void Process() {
        MyData data = _provider.getData();
        ...
    }
}

The lifetime of the "Foo" object lasts as long as the application. The provider has no internal state.

My opinion is that I'd prefer option 2. Why constantly new up an object that will be quickly garbage collected afterwards? In this particular case, the provider object is very lightweight and, as I said, has no state so I felt why not just keep it around for the life of the consuming object. I think the counter argument is that keeping it scoped to the method will free up memory (which I feel is splitting hairs since it's not a heavy object to begin with).

This is C# / .NET but would apply to many other frameworks.

Noodleface · Jan 30, 2020

Prefer the first

ShakyJake · Jan 30, 2020

Noodleface said:
Prefer the first

Why?

Think of it this way: typical dependency injection follows the same pattern as the second. Object is injected into the constructor and saved as a private member. It's instance lasts as long as the consuming object.

Noodleface · Jan 31, 2020

I understand your point. I just prefer to keep memory alloc/dealloc contained if possible. I probably wouldn't pull it out of that member unless others needed it too. I'm thinking about scope.

Lendarios · Jan 31, 2020

first is wrong.

MyProvider provider = new MyProvider(); can be an intensive operation, it is better to do it only once.

better yet make it a singleton, that way it is instantiated 1 across multiple foos

For example if MyProvider were a connection to AWS then it will SLOOWWWWWW down a lot as it has to go outside your system boundaries.

Also if you can put it as a dependency injection, that would be ideal, so much cleaner.

Noodleface · Jan 31, 2020

It's not wrong, too many variables to say that

Lendarios · Jan 31, 2020

Noodleface said:
It's not wrong, too many variables to say that

Disagree.

Constructors are used for that, to instantiate values that are used on the method, and then you dealocate them on the destructor.
Especially if you are calling the same thing multiple times over the lifecycle of the object.

If you don't want to do initialization upfront. Lazy initialization is a thing.

Lazy Initialization - .NET Framework

Explore lazy initialization in .NET, a performance improvement that means an object creation is deferred until the object is first used.

docs.microsoft.com

With The AWS spread, and s3 bucket uploading and SQS messagin, if you instantiate the connection to the s3 bucket, everytime you call it.. then you are in a world of hurt. (performance wise), you create the client once and reuse it.

Lendarios · Jan 31, 2020

ShakyJake
Dependency injection is SOOO much nicer than the old styles.

Try to push your team towards it.

Noodleface One technical downside of the first approach is that you can not to unit test on it. You can not mock the provider, so you cant built a unit test to verify the method actually works.

ShakyJake tell them the second approach is better categorically and add a contructor that takes a provider

Code:

public Foo (MyProvider prov)
{
this._provider = prov
}

then you can mock that and the result on a unit test.

it is ok to have multiple contructors

Noodleface · Jan 31, 2020

I don't work in a world where unit tests exist. I also don't work in AWS

In terms of memory management neither are wrong, I just prefer the second.

ShakyJake · Jan 31, 2020

Lendarios said:
ShakyJake
Dependency injection is SOOO much nicer than the old styles.

Try to push your team towards it.

We're already doing this in our other (dotnet core) app. This particular example is from an old ass Windows service application. Granted, we could do DI 'manually' but it isn't worth the trouble.

Anyway, that wasn't really my argument. My concern was constantly creating/destroying objects in rapid succession. Like I mentioned, this method is called frequently. Frequently meaning numerous times a minute.

ShakyJake · Jan 31, 2020

Noodleface said:
I don't work in a world where unit tests exist.

That's not possible. Unless you're not coding.

Lendarios · Jan 31, 2020

Even without DI, you get performance and testing benefits by going the second route. Win/win

Noodleface · Jan 31, 2020

ShakyJake said:
That's not possible. Unless you're not coding.

I do code. We don't have unit tests like the ones lendarios is talking about, not possible for what we write.

Search

IT/Software career thread: Invert binary trees for dollars.

chaos

Buzzfeed Editor

Lendarios

Trump's Staff

Noodleface

A Mod Real Quick

Deebo

Molten Core Raider

chaos

Buzzfeed Editor

TJT

Mr. Poopybutthole

Noodleface

A Mod Real Quick

ShakyJake

Noodleface

A Mod Real Quick

ShakyJake

Noodleface

A Mod Real Quick

Lendarios

Trump's Staff

Noodleface

A Mod Real Quick

Lendarios

Trump's Staff

Lazy Initialization - .NET Framework

Lendarios

Trump's Staff

Noodleface

A Mod Real Quick

ShakyJake

ShakyJake

Lendarios

Trump's Staff

Noodleface

A Mod Real Quick