Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›434 »

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Bongo Bill posted:

and by extension how to write code that it's possible to write a good unit test around

This is why I recommend everyone learn and use TDD for exactly one project.

# ? Jan 4, 2018 21:59

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 17:23

Bongo Bill: Jan 17, 2012

Vulture Culture posted:

This is why I recommend everyone learn and use TDD for exactly one project.

This is absolutely the best way to learn it, but the opportunity may not arise for some.

# ? Jan 4, 2018 22:02

KoRMaK: Jul 31, 2012

Small, single purpose classes, and tests to go with them.

# ? Jan 4, 2018 22:32

JawnV6: Jul 4, 2004; So hot ...

Cool, buncha application devs telling embedded folks to focus on unit testing, love it.

# ? Jan 4, 2018 22:52

Brain Candy: May 18, 2006

JawnV6 posted:

Cool, buncha application devs telling embedded folks to focus on unit testing, love it.

Friend, have you heard the good word about property testing?

# ? Jan 4, 2018 22:58

FlapYoJacks: Feb 12, 2009

JawnV6 posted:

Cool, buncha application devs telling embedded folks to focus on unit testing, love it.

I am a embedded Linux Dev and unit test. I even set up kernel drivers to emulate hardware (as best as I can). All of my code works in x86 as well.

Now bare metal? Eh.....

# ? Jan 4, 2018 23:02

RussianBear: Sep 14, 2003; I am become death, the destroyer of worlds

Rocko Bonaparte posted:

I can point you to some particular design patterns and topics if there's a specific activity you're doing. The rest of this thread will likely then jump right in too. Assuming you're writing software within or just in proximity of an electrical engineering discipline, then I have some free advice on stuff like:
1. Equipment control wrappers
2. Coordinating experiments
3. Elevated shell scripting ("elevated" as in "slightly more sophisticated than a few lines of bash or bat" instead of "running as Admin/root")
4. Data collection and dispersal

Awesome. I don't have any relevant projects that I'm working on now, so I'll use a past project as an example. I had some custom hardware that took measurements and streamed the results to a PC over a serial connection. The PC was running a python script that monitored everything and logged the data to a text file. Now let's say I wanted to add an internet connection to the hardware so that the data could be logged to a database in the cloud and the hardware could be monitored and controlled by a web app. What are things to keep in mind when designing, building, and testing such a system?

# ? Jan 4, 2018 23:11

Murrah: Mar 22, 2015

My boss has a dog that sometimes misbehaves, he started yelling at it the dog today while I waited on the screen share dev call for a minute or two it was really loud and then just kind of acted like nothing happened and continued with the call.

Remote work life stories yall.

# ? Jan 4, 2018 23:16

JawnV6: Jul 4, 2004; So hot ...

ratbert90 posted:

I am a embedded Linux Dev and unit test. I even set up kernel drivers to emulate hardware (as best as I can). All of my code works in x86 as well.

Now bare metal? Eh.....

Yeah, I'm coming from more of a bare metal background and found the TDD approach on one project particularly worthless. Didn't flush out a single application bug, hardware testing with simulated delays (and lack thereof) was significantly more useful. Rocko's advice was much more relevant and on point.

It's just cargo culting. What does an EE rat's nest of code look like? What practices would improve it? I dunno, but unit testing's pretty neat! Let's recommend that!

I am literally an EE who now works as a software developer. The lowest hanging fruit in most of the EE code I've seen would be vastly improved by: whitespace

# ? Jan 4, 2018 23:20

AskYourself: May 23, 2005; Donut is for Homer as Asking yourself is to ...

It's hard to act professional when you don't wear pants ?

# ? Jan 4, 2018 23:20

Rubellavator: Aug 16, 2007

TDD people are like vegans.

# ? Jan 4, 2018 23:26

Bongo Bill: Jan 17, 2012

The advice was intended as a path for an electrical engineer to voluntarily improve their understanding of software engineering, not as a way to fix horrible embedded codebases. Self-improvement only. It's a new year, after all.

# ? Jan 4, 2018 23:26

spiritual bypass: Feb 19, 2008; Grimey Drawer

You should write command line tools for yourself in Racket

# ? Jan 4, 2018 23:51

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

RussianBear posted:

Awesome. I don't have any relevant projects that I'm working on now, so I'll use a past project as an example. I had some custom hardware that took measurements and streamed the results to a PC over a serial connection. The PC was running a python script that monitored everything and logged the data to a text file. Now let's say I wanted to add an internet connection to the hardware so that the data could be logged to a database in the cloud and the hardware could be monitored and controlled by a web app. What are things to keep in mind when designing, building, and testing such a system?

Stuff like this is great for learning abstraction because the places where you'd personally tend to use the word "interface" are also the places where you'd use the term "interface" in object-oriented programming. A major problem I have with folks used to the more physical definition of an interface is that they think the use of interfaces in most of the design patterns are hippy mad science. Having them be more literal makes for an easier stepping stone. Assuming your system architecture is like:
1. Web stack you can partially control
2. PC application you can totally control
3. Hardware/embedded system you can totally control, but changing it might make you want to kill yourself

You probably already treat each boundary as having an interface, so you can just formalize that in software as a series of general-purpose functions. The PC application's deepest internals then are just preoccupied with expectations for both ends of the stack without delving into any specifics. Once you do this, you can swap out the literal implementations like nothing--particularly to switch in stuff that can generate/receive mock data and test it.

Assuming the web stack kind of scares you, it's nice to know you at least have declared what it expects to see and can feed it bullshit data consistent with what it would normally get without having to worry about setting up the entire thing just to try stuff out. Having this disconnection lets you work on the web app independently of everything else, and all you have to worry about is how you're going to get stuff coming in from the web app to reach the interface that takes it to the PC app.

The important reason to decouple like that is so when something goes wrong, you don't get that sudden sense of dread that "it could be anywhere!" Especially if it goes wrong from a known input, you can just make your sock puppet implementations act just like that input and see which part falls over.

Anyways I can get much more specific but I suspect some folks will first come in to suggest some different outcomes. My specifically summary would be the PC would be serving as a bridge, and also possibly a publisher in a publish-subscribe model for the logging. The web stack has its own model-view-controller crap going on, but it stays there, in its little box, under the larger system. What happens at the hardware level is extremely contextual.

By far the worst part of the whole thing is that you're likely having to poll the hardware for some kind of period measurement, and running tests with that interval gets really boring. You can replace all your sleep and timing logic with an intermediary that can use the regular sleep and date calls normally, but switch to an alternate space where sleeps do nothing but increment your fake time when testing. This makes testing instantaneous. This all goes to poo poo if you decide to use multiple threads that are sleeping in their own intervals.

# ? Jan 5, 2018 00:38

geeves: Sep 16, 2004

Rubellavator posted:

TDD people are like vegans.

# ? Jan 5, 2018 01:16

baquerd: Jul 2, 2007; by FactsAreUseless

Rubellavator posted:

TDD people are like vegans.

They kill babies via malnutrition?

# ? Jan 5, 2018 13:48

sarehu: Apr 20, 2007; (call/cc call/cc)

They buy the crib and clothes and paint the nursery before conceiving the child.

# ? Jan 5, 2018 16:49

fantastic in plastic: Jun 15, 2007; The Socialist Workers Party's newspaper proved to be a tough sell to downtown businessmen.

Rubellavator posted:

TDD people are like vegans.

They don't consume animal products?

# ? Jan 5, 2018 17:20

Portland Sucks: Dec 21, 2004; à¼¼ ã¤ â_â à¼½ã¤

What is it with this place and people sending all hands e-mails.

This guy just apparently resigned/got another job or something

quote:

As many of you know, today is my last day of employment at <company>. While I am excited about the future opportunities I am moving on to, I am saddened..blah blah blah

...

Typically I would never be so audacious to send an �all hands� email for a personal message; however, I want to leave you with my hopes for the future of this organization and what EVERY person should be doing to support that.

bitch

# ? Jan 5, 2018 17:36

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

sarehu posted:

They buy the crib and clothes and paint the nursery before conceiving the child.

Those are common first date activities for TDD-sexuals.

# ? Jan 5, 2018 18:10

Pollyanna: Mar 5, 2005; Milk's on them.

TDD is a good experience to go through but it is not always appropriate.

# ? Jan 5, 2018 18:22

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I had a coworker who I normally respected demand TDD from an intern without having any scaffolding code whatsoever. In other words, he wanted to see a test before even the interfaces were declared. I had to tell him to think that one all the way through.

# ? Jan 5, 2018 18:23

ChickenWing: Jul 22, 2010

@Test
public void testThisNewThing() {
Assert.fail(); //TODO: update when code actually exists
}

# ? Jan 5, 2018 18:45

Bongo Bill: Jan 17, 2012

A test that doesn't compile counts as a failing test.

# ? Jan 5, 2018 18:47

Portland Sucks: Dec 21, 2004; à¼¼ ã¤ â_â à¼½ã¤

RussianBear posted:

I'm an electrical engineer and I realize my code would make software engineers weep. Are there any resources that you can recommend? I want to be one of the ones that turns around.

I'll explain some of the things that make me want to end my life that the EE's believe about software development. If you do any of these just do the opposite and we can be friends.

1) Writing tests is a waste of time because the "real world" is too complicated and your tests will always fail so just never use them.

2) OOP is just over complicating things, if you can write all of your code procedural in one big file you should.

3) Reusable code means code I can copy and paste from one thing to another.

4) Version control is a nice thought but not applicable in a production environment.

5) You should be able to do everything in VB, or at the most complex Python. If you can't then it's because the Python development team is obviously failing. This includes things like touch screen HMIs and real time systems.

6) The best code is code that can be maintained by non-developers. If you can write a program using nothing more complex than If/Then statements that's the best kind of code.

7) The only acceptable third party libraries are database connectors.

# ? Jan 5, 2018 20:33

CPColin: Sep 9, 2003; Big ol' smile.

ChickenWing posted:

@Test
public void testThisNewThing() {
Assert.fail(); //TODO: update when code actually exists
}

I've seen a handful of tests so far during my first week and all but one look exactly like this:

code:

@TestFor(Thing)
class ThingSpec extends Specification {

    def setup() {
    }

    def cleanup() {
    }

    void "test something"() {
        expect:"fix me"
            true == false
    }
}

# ? Jan 5, 2018 20:49

LLSix: Jan 20, 2010; The real power behind countless overlords

Votlook posted:

I work at a small company with a few other devs, the CEO just informed us that the CTO (my direct manager) will be devoting all his time on completely rewriting our core product completely on his own, and no longer manage the dev team.

I should start sending out resumes, right?

Yes, but while you're doing that it sounds like your company has a management opening. Could be a good opportunity if that's something you're interested in. It's not like you can do a worse job than the last guy.

# ? Jan 5, 2018 22:30

ChickenWing: Jul 22, 2010

Portland Sucks posted:

I'll explain some of the things that make me want to end my life that the EE's believe about software development. If you do any of these just do the opposite and we can be friends.

1) Writing tests is a waste of time because the "real world" is too complicated and your tests will always fail so just never use them.

2) OOP is just over complicating things, if you can write all of your code procedural in one big file you should.

3) Reusable code means code I can copy and paste from one thing to another.

4) Version control is a nice thought but not applicable in a production environment.

5) You should be able to do everything in VB, or at the most complex Python. If you can't then it's because the Python development team is obviously failing. This includes things like touch screen HMIs and real time systems.

6) The best code is code that can be maintained by non-developers. If you can write a program using nothing more complex than If/Then statements that's the best kind of code.

7) The only acceptable third party libraries are database connectors.

Wow gently caress EEs

CPColin posted:

I've seen a handful of tests so far during my first week and all but one look exactly like this:

seriously our primary codebase is (according to sonar) 113k LOC with 3k unit tests and that's often not enough, how the hell rear end do other programs not break all to hell literally all of the time

# ? Jan 5, 2018 22:30

Che Delilas: Nov 23, 2009; FREE TIBET WEED

ChickenWing posted:

seriously our primary codebase is (according to sonar) 113k LOC with 3k unit tests and that's often not enough, how the hell rear end do other programs not break all to hell literally all of the time

As long as you use it exactly this way and do not deviate and do not make a mistake, it works fine. :colbert:

# ? Jan 5, 2018 22:43

redleader: Aug 18, 2005; Engage according to operational parameters

ChickenWing posted:

seriously our primary codebase is (according to sonar) 113k LOC with 3k unit tests and that's often not enough, how the hell rear end do other programs not break all to hell literally all of the time

You tiptoe around the existing code base, work very slowly and delicately, rely on the guy who's been involved in the code for nearly 20 years to catch any huge fuckups, and let ops sort the rest out.

# ? Jan 5, 2018 23:14

Bongo Bill: Jan 17, 2012

ChickenWing posted:

seriously our primary codebase is (according to sonar) 113k LOC with 3k unit tests and that's often not enough, how the hell rear end do other programs not break all to hell literally all of the time

Their maintainers work harder and under conditions of elevated stress in order to compensate.

There are better ways.

# ? Jan 5, 2018 23:17

taqueso: Mar 8, 2004

Bongo Bill posted:

This is absolutely the best way to learn it, but the opportunity may not arise for some.

Ehh, everyone can make a little side project to try out a new dev technique if they are actually interested.

# ? Jan 5, 2018 23:22

Portland Sucks: Dec 21, 2004; à¼¼ ã¤ â_â à¼½ã¤

ChickenWing posted:

Wow gently caress EEs

seriously our primary codebase is (according to sonar) 113k LOC with 3k unit tests and that's often not enough, how the hell rear end do other programs not break all to hell literally all of the time

Our main application is approaching 50k LOC with 0 tests. :allears:

# ? Jan 5, 2018 23:31

Dr. Arbitrary: Mar 15, 2006; Bleak Gremlin

I started a job with a real Dev team this week. I've been a sysadmin for years and I know the basics of coding (I think I'm pretty good at Powershell!)

I'm supposed to be doing QA and testing. I've gotten Selinium working, but I'm curious if there are options that are more in line with contemporary practices.

Anyone have a good idea on how to start learning how to test software properly?

Edit: looks like that's already being discussed. Awesome!

Dr. Arbitrary fucked around with this message at 00:22 on Jan 6, 2018

# ? Jan 6, 2018 00:11

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

ChickenWing posted:

Wow gently caress EEs

That is kind of severe though but the ones that stick with it need forced re-education.

I can think of a few more:
1. "Python's great because I can get a few lines of code working at one time, paste them into a file, and then just run the whole file later to reproduce what I did."
2. A script is "robust" if it runs more than once.
3. Don't even bother looking for 3rd-party libraries that might help online. They simply don't exist. Nobody has ever done what you are doing before because your work is elite.
4. If something goes uncharacteristically wrong, then return 11. I personally still don't get this. I guess because it's two one's instead of just one.
5. If an exception is raised when using somebody else's code, it's clearly their fault because I'm not working with exceptions.
6. In dynamically-typed languages, it's great that I can assign different data types to the same variable as it meanders through 10,000 lines of code. It keeps me from having to declare new variables, which is inefficient.

# ? Jan 6, 2018 04:06

Winter Stormer: Oct 17, 2012

Rocko Bonaparte posted:

"Python's great because I can get a few lines of code working at one time, paste them into a file, and then just run the whole file later to reproduce what I did."

This, but with MATLAB :stonk:

# ? Jan 6, 2018 05:53

Paolomania: Apr 26, 2006

I don't necessarily believe in TDD as a specific methodology, but I do believe in getting test coverage up as high as possible before submitting changes. There is no proof of the value of tests like the experience of making "one small change" in some well tested code and watching every test blow up. That is when you realize that tests should be the gravity that topples bad code.

# ? Jan 6, 2018 06:40

KoRMaK: Jul 31, 2012

Dr. Arbitrary posted:

I started a job with a real Dev team this week. I've been a sysadmin for years and I know the basics of coding (I think I'm pretty good at Powershell!)

I'm supposed to be doing QA and testing. I've gotten Selinium working, but I'm curious if there are options that are more in line with contemporary practices.

Anyone have a good idea on how to start learning how to test software properly?

Edit: looks like that's already being discussed. Awesome!

When we first started rolling our test suite out, and we couldn't really write unit tests because our stuff was so intertwined, I asked how we could just simulate user input. The consultant hooked me up with selenium and capybara and stuff. Then... then I had an epiphany. I could point this loving script at any arbitrary domain and have it interact with the webpage. That's when I realized that you could weponize testing suites and how I learned to make my first web scrapers and bots

# ? Jan 6, 2018 06:59

Dr. Arbitrary: Mar 15, 2006; Bleak Gremlin

I'm just wishing I had known about Selenium earlier in my career. There's a zillion applications out there that I've had to maintain that had no API or CLI.

# ? Jan 6, 2018 07:02

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 17:23

Carbon dioxide: Oct 9, 2012

Dr. Arbitrary posted:

I'm just wishing I had known about Selenium earlier in my career. There's a zillion applications out there that I've had to maintain that had no API or CLI.

Does this thread have opinions on Selenium vs Cucumber testing? As far as I know, cucumber is mostly a layer that exists on top of selenium that makes the test cases that are being executed more human-readable but it's quite possible it adds a lot more functionality.

By the way, if there's one thing I learned about testing during my career so far, it's that while developers SHOULD be writing unit tests whenever possible, and especially for algorithmically complex code, it's also extremely valuable to have a dedicated test engineer in your development team, who takes care of and updates browser/UI tests, does manual testing of new functionality, and discusses options for automatic integration tests and the like with the rest of the team.

People, especially managers, consistently underestimate how many bugs you can remove pre-release by just having a full-time test engineer on board. Mostly because test engineers can look at it freshly, while developers such as myself tend to get so deep into the code site of things that they tend to lose track of some minor aspects of the functionality, so if they have to test their own stuff, they tend to miss those things.

Convince your management to hire a test engineer, if you can. It's fully worth it.

# ? Jan 6, 2018 11:24

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›434 »