Ask General Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ask General Programming Questions Not Worth Their Own Thread

«‹›671 »

Good Will Hrunting: Oct 8, 2012; I changed my mind.
I'm not sorry.

Sedro posted:

You can still view the lectures and submit assignments for grading. You just won't have a weekly deadline if that's something you need for motivation.

There are good resources on the official website. You'll want to use IDEA.

Feel free to ask any questions here.

I might give that a shot, thanks. I've got the upgraded IDEA as I've done some Play stuff in Java.

GrumpyDoctor posted:

I know this doesn't answer your question, but did your team lead provide a reason for this suggestion?

"Scala is perfect for writing REST APIs and will let us do things quicker with less code thats also cleaner". He also really hates Java (we use Dropwizard now).

# ? Nov 23, 2014 21:19

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 10:15

KoRMaK: Jul 31, 2012

Switch/case vs if/elseif: Which is better style wise?

# ? Nov 24, 2014 02:15

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Whichever one is easiest to do for the thing you're evaluating?

# ? Nov 24, 2014 02:17

KoRMaK: Jul 31, 2012

LeftistMuslimObama posted:

Whichever one is easiest to do for the thing you're evaluating?

The way switch/case indents in ruby looks weird, so I don't like it. Someone at work is changing my elsifs to cases and I need to get my head straight on if I should give a poo poo.

# ? Nov 24, 2014 02:19

JawKnee: Mar 24, 2007; You'll take the ride to leave this town along that yellow line

KoRMaK posted:

Switch/case vs if/elseif: Which is better style wise?

kind of depends on what you're doing and to a lesser extent what language you're using

# ? Nov 24, 2014 02:24

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

KoRMaK posted:

The way switch/case indents in ruby looks weird, so I don't like it. Someone at work is changing my elsifs to cases and I need to get my head straight on if I should give a poo poo.

If your coworker is passive-aggressively making commits just to change your if-else ladders into switch-case things, you should definitely care a little just because that sort of workplace culture is really toxic and is going to cause other issues unless you sit down and talk about it.

On the other hand, if they're just adding another branch to that area and refactoring it into a switch-case while they're there (because now it has enough cases to justify doing it), it doesn't seem like a big deal.

Does your workplace have a style guide for how code is supposed to look? If so, it should cover this sort of situation, and if not, you should probably get one.

# ? Nov 24, 2014 03:06

KoRMaK: Jul 31, 2012

Jabor posted:

If your coworker is passive-aggressively making commits just to change your if-else ladders into switch-case things, you should definitely care a little just because that sort of workplace culture is really toxic and is going to cause other issues unless you sit down and talk about it.

On the other hand, if they're just adding another branch to that area and refactoring it into a switch-case while they're there (because now it has enough cases to justify doing it), it doesn't seem like a big deal.

Does your workplace have a style guide for how code is supposed to look? If so, it should cover this sort of situation, and if not, you should probably get one.

It's me, I'm (I guess) supposed to be in charge of that stuff. We are pretty small, and currently I'm the programmer that has been there the longest.

I figured, as is customary here, to do it semi-informally by talking with him about it. But Its looking more and more like I need to set a style guide because the current directive of "blend in with the code around it and explore the code to see our conventions and how we currently do stuff" isn't explicit enough.

KoRMaK fucked around with this message at 03:44 on Nov 24, 2014

# ? Nov 24, 2014 03:11

Hughlander: May 11, 2005

Good Will Hrunting posted:

One of my team leads has suggested we start rewriting one of our APIs in Scala and I've never touched Scala. There used to be a thread but I don't see it anymore. Anyone have good resources for learning? I know Odersky has a Coursera course but I just missed the last run of it.

I worked at a place that did something like that. Code in Java, tests in Scala. Don't do this. The build/debug environment is poo poo and any productivity increase you get over time is eaten by learning and iteration time. Not to mention its a million times easier to get competent Java developers as Scala so you will constantly eat that learning time.

# ? Nov 24, 2014 04:31

Good Will Hrunting: Oct 8, 2012; I changed my mind.
I'm not sorry.

Hughlander posted:

I worked at a place that did something like that. Code in Java, tests in Scala. Don't do this. The build/debug environment is poo poo and any productivity increase you get over time is eaten by learning and iteration time. Not to mention its a million times easier to get competent Java developers as Scala so you will constantly eat that learning time.

I'm not sure how much performance increase we'd see (if any). Dropwizard is supposedly really fast, and we're not going to be servicing a lot of requests or sending a lot of data back at all for quite some time. The argument seems to be "less code".

Then again, I'm just the lowly Junior dev.

# ? Nov 24, 2014 04:39

Hughlander: May 11, 2005

Good Will Hrunting posted:

I'm not sure how much performance increase we'd see (if any). Dropwizard is supposedly really fast, and we're not going to be servicing a lot of requests or sending a lot of data back at all for quite some time. The argument seems to be "less code".

Then again, I'm just the lowly Junior dev.

It's not a clock time increase its a productive increase. Given two developers with two+ years experience one in Java one in Scala, the Scala one will on average get more done in less time. But they just aren't as productive while getting there. At the place I mentioned people hated writing tests more than any other place purely due to having to write Scala. Which ultimately was a negative to the company.

# ? Nov 24, 2014 04:54

Gul Banana: Nov 28, 2003

technically, this is an argument about never doing or using anything new if it takes time to change from old to new

it might not be worth it for any given organisation to make the change, but if the new stuff really is more productive, surely it should happen eventually - there should be a point where people already have the experience and the switching costs are gone.

# ? Nov 24, 2014 05:41

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

KoRMaK posted:

It's me, I'm (I guess) supposed to be in charge of that stuff. We are pretty small, and currently I'm the programmer that has been there the longest.

I figured, as is customary here, to do it semi-informally by talking with him about it. But Its looking more and more like I need to set a style guide because the current directive of "blend in with the code around it and explore the code to see our conventions and how we currently do stuff" isn't explicit enough.

As the most senior engineer, you need to understand how to pick your battles, for multiple reasons.

For one, every conflict you start, no matter how minor, costs you something politically: with your coworkers, with your bosses, with your customers, whatever. If your coworkers start thinking of you as "that jerk who needs every little thing go their way", they will tune you out, or worse, start resenting you and resisting your suggestions; and they will do this not just for the fiddly details that you aren't even sure that you care about, but for the important architectural decisions where you really do have important things to say. This doesn't mean you can't have standards and conventions, but at the very least you need to get your entire team invested in them so that critical reviews don't 100% seem to come from you. This is especially true if you don't have all that much credibility to begin with, e.g. if having been there the longest means you got hired two months before the others.

That's the usual sense of "pick your battles", but there's another, which is that it can be actively helpful to let other people win. People want to feel that they have some control, some input into how things are done. The more comfortable they are, and the more respected they feel, the more willing they'll be to make suggestions about other things. Presumably they were hired with the hope that not all their ideas would prove to be worthless. Again, of course, this doesn't mean that you shouldn't have a voice of your own, or that you should let every decision turn into a committee quagmire; if you have some sort of technical authority, it's probably for a reason. But you don't have to decide everything, and even when you helped shape the consensus, it can be good to let somebody else step up and take (most of) the credit.

So I guess what I'm saying is that I would not advise starting even a minor conflict with your coworker over if-chains vs. switch. But if you care, you could probably raise it in a non-confrontational way � maybe mentioning that you were thinking of using a switch yourself, and you're thinking about these trade-offs � and then capture the result of that (brief) discussion in some way that will gradually evolve into a coding standard. And be prepared to give in if it seems to matter a lot more to your coworker than it does to you.

# ? Nov 24, 2014 06:28

Forgall: Oct 16, 2012; by Azathoth

rjmccall posted:

For one, every conflict you start, no matter how minor, costs you something politically: with your coworkers, with your bosses, with your customers, whatever. If your coworkers start thinking of you as "that jerk who needs every little thing go their way", they will tune you out, or worse, start resenting you and resisting your suggestions; and they will do this not just for the fiddly details that you aren't even sure that you care about, but for the important architectural decisions where you really do have important things to say.

Is that, like, normal? It sounds like working with a bunch of spoiled children.

# ? Nov 24, 2014 15:48

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

Forgall posted:

Is that, like, normal? It sounds like working with a bunch of spoiled children.

The gamut of personality traits that you will find in the real world is complicated and not all of them can be written of as babies and spoiled children. As a leader or someone with seniority it's important to learn these things about your coworkers so that you can take a stance on things that matter and not lose credibility fighting over the minutiae.

# ? Nov 24, 2014 18:02

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Forgall posted:

Is that, like, normal? It sounds like working with a bunch of spoiled children.

Umm, this is what it is to live with human beings.

It's rarely just that explicit, but its a death by a thousand cuts type of thing.

# ? Nov 24, 2014 18:20

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Forgall posted:

Is that, like, normal? It sounds like working with a bunch of spoiled children.

Above and beyond the normal "people get defensive and claim ownership over weird things", we happen to work in an industry where 60+% of the people see themselves as uniquely brilliant Randian ubermensch who are the only ones doing anything right.

# ? Nov 24, 2014 18:24

Forgall: Oct 16, 2012; by Azathoth

I haven't really run into that. But then again I haven't been in a senior role, so such conflicts might have gone over my head. Still, team members getting all catty and holding grudges like that seems strange.

LeftistMuslimObama posted:

Above and beyond the normal "people get defensive and claim ownership over weird things", we happen to work in an industry where 60+% of the people see themselves as uniquely brilliant Randian ubermensch who are the only ones doing anything right.

Could be cultural difference too. In Russia it's usually just "shut up and do what the boss tells you".

Forgall fucked around with this message at 18:31 on Nov 24, 2014

# ? Nov 24, 2014 18:29

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Forgall posted:

Is that, like, normal? It sounds like working with a bunch of spoiled children.

Have you never had an argument with a friend or something?

# ? Nov 24, 2014 18:41

Forgall: Oct 16, 2012; by Azathoth

Suspicious Dish posted:

Have you never had an argument with a friend or something?

An argument after which they hold a grudge forever to the point where they turn down good advice or help out of spite? I don't think so.

# ? Nov 24, 2014 18:43

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Forgall posted:

An argument after which they hold a grudge forever to the point where they turn down good advice or help out of spite? I don't think so.

It's not good advice or help, it's petty bullshit. And it's because you keep insisting on these things, it's not out of spite.

# ? Nov 24, 2014 18:44

Forgall: Oct 16, 2012; by Azathoth

Suspicious Dish posted:

It's not good advice or help, it's petty bullshit. And it's because you keep insisting on these things, it's not out of spite.

I'm referring to the part I quoted, specifically

quote:

If your coworkers start thinking of you as "that jerk who needs every little thing go their way", they will tune you out, or worse, start resenting you and resisting your suggestions; and they will do this not just for the fiddly details that you aren't even sure that you care about, but for the important architectural decisions where you really do have important things to say.

# ? Nov 24, 2014 18:46

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Forgall posted:

An argument after which they hold a grudge forever to the point where they turn down good advice or help out of spite? I don't think so.

The point is more that if the changes the guy is making don't actually alter the functionality of the code or make it less readable, there's no good reason to confront him about it because you never know how he'll take it. If he was doing stuff that actually makes your product worse, than you should by all means smack him down because his feelings don't matter at that point.

# ? Nov 24, 2014 18:50

KoRMaK: Jul 31, 2012

rjmccall posted:

As the most senior engineer, you need to understand how to pick your battles, for multiple reasons.

For one, every conflict you start, no matter how minor, costs you something politically: with your coworkers, with your bosses, with your customers, whatever. If your coworkers start thinking of you as "that jerk who needs every little thing go their way", they will tune you out, or worse, start resenting you and resisting your suggestions; and they will do this not just for the fiddly details that you aren't even sure that you care about, but for the important architectural decisions where you really do have important things to say. This doesn't mean you can't have standards and conventions, but at the very least you need to get your entire team invested in them so that critical reviews don't 100% seem to come from you. This is especially true if you don't have all that much credibility to begin with, e.g. if having been there the longest means you got hired two months before the others.

That's the usual sense of "pick your battles", but there's another, which is that it can be actively helpful to let other people win. People want to feel that they have some control, some input into how things are done. The more comfortable they are, and the more respected they feel, the more willing they'll be to make suggestions about other things. Presumably they were hired with the hope that not all their ideas would prove to be worthless. Again, of course, this doesn't mean that you shouldn't have a voice of your own, or that you should let every decision turn into a committee quagmire; if you have some sort of technical authority, it's probably for a reason. But you don't have to decide everything, and even when you helped shape the consensus, it can be good to let somebody else step up and take (most of) the credit.

So I guess what I'm saying is that I would not advise starting even a minor conflict with your coworker over if-chains vs. switch. But if you care, you could probably raise it in a non-confrontational way � maybe mentioning that you were thinking of using a switch yourself, and you're thinking about these trade-offs � and then capture the result of that (brief) discussion in some way that will gradually evolve into a coding standard. And be prepared to give in if it seems to matter a lot more to your coworker than it does to you.

Nah man, coding is a meat-grinder and as a senior I have to turn the handle :unsmigghh:

But seriously, I agree with everything you said here. Especially the bolded parts - that's where some top notch insight is.

# ? Nov 24, 2014 18:53

Forgall: Oct 16, 2012; by Azathoth

LeftistMuslimObama posted:

The point is more that if the changes the guy is making don't actually alter the functionality of the code or make it less readable, there's no good reason to confront him about it because you never know how he'll take it. If he was doing stuff that actually makes your product worse, than you should by all means smack him down because his feelings don't matter at that point.

No, I get that part. I was just surprised that it's considered to be a normal thing to expect from your co-workers that they'll sabotage the project out of spite somewhere down the line because of a tiny disagreement.

# ? Nov 24, 2014 18:57

Eggnogium: Jun 1, 2010; Never give an inch! Hnnnghhhhhh!

Forgall posted:

No, I get that part. I was just surprised that it's considered to be a normal thing to expect from your co-workers that they'll sabotage the project out of spite somewhere down the line because of a tiny disagreement.

That's not what was described at all. You've never, ever worked with someone who was perceived as a micromanager/controlling/anal? The point was this is the kind of thing that can start to build up those perceptions and then even good suggestions from that person will be perceived through that lens.

# ? Nov 24, 2014 19:11

Forgall: Oct 16, 2012; by Azathoth

Eggnogium posted:

That's not what was described at all. You've never, ever worked with someone who was perceived as a micromanager/controlling/anal? The point was this is the kind of thing that can start to build up those perceptions and then even good suggestions from that person will be perceived through that lens.

I suppose not. If anything, places where I've worked had opposite problem.

# ? Nov 24, 2014 19:21

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Ideally, in a workplace, a good manager will keep things on an even keel proactively, and even a mediocre manager should recognize when they need to step in before the relationship becomes so poisoned that one person is completely ignoring the other; but not all managers are mediocre or better. I've been on teams where the manager had to tell two people not to review each other's code anymore; yes, I thought letting the dispute get so far out of hand was childish and unprofessional on both their parts (and probably more the fault of the one I was/am friends with, unfortunately), but sometimes people have issues that come out in their work.

Have you never heard any of those hoary old proverbs about the dangers of giving advice? Even at work, people get touchy about being told how to do their business, especially when you're not actually their boss.

# ? Nov 24, 2014 19:23

ToxicFrog: Apr 26, 2008

Forgall posted:

I suppose not. If anything, places where I've worked had opposite problem.

It's a cry-wolf thing. If you spend months where every suggestion you make is tedious, irrelevant bullshit, people start to optimize by assuming that that's all you produce, which is a problem when you have something to say later that isn't tedious, irrelevant bullshit but which everyone automatically assumes must be.

# ? Nov 24, 2014 19:51

Forgall: Oct 16, 2012; by Azathoth

Ok, fair enough. I guess I was approaching it from "how things should be" perspective, not "how they are". And in the real world idealistic perspective is pretty useless.

# ? Nov 24, 2014 20:06

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Hughlander posted:

Code in Java, tests in Scala.

What was the rational behind that? I can't really think of any scenario where I'd even consider having the code and tests in different languages other than things like writing a library for a scripting language.

# ? Nov 25, 2014 04:44

Kenishi: Nov 18, 2010

rjmccall posted:

But if you care, you could probably raise it in a non-confrontational way � maybe mentioning that you were thinking of using a switch yourself, and you're thinking about these trade-offs � and then capture the result of that (brief) discussion in some way that will gradually evolve into a coding standard. And be prepared to give in if it seems to matter a lot more to your coworker than it does to you.

I don't remember where I heard it before, but one of the best ways with dealing with your boss or your boss's boss, isn't to tell them they are wrong; it's to guide them to see what the ideal solution is and have them believe they found it. You get what you want, they feel good as well, and you are likely to get more sway in the future. So this isn't just "coding standards," its tactics for getting ahead in the office.

# ? Nov 25, 2014 11:07

baquerd: Jul 2, 2007; by FactsAreUseless

Plorkyeran posted:

What was the rational behind that? I can't really think of any scenario where I'd even consider having the code and tests in different languages other than things like writing a library for a scripting language.

They run on the JVM, and you can call Java from Scala and vice versa natively, so you don't have any crazy integration issues and it basically just works out of the box. Scala tests do have a certain elegance to them Java tests lack, and I'd call it similar to using a library like Cucumber. I don't know if I'd ever mix the two, but I've worked on both Scala and Java projects and I see where the idea comes from.

Scala:

code:

class ExampleSpec extends FlatSpec with Matchers {

  "A Stack" should "pop values in last-in-first-out order" in {
    val stack = new Stack[Int]
    stack.push(1)
    stack.push(2)
    stack.pop() should be (2)
    stack.pop() should be (1)
  }

  it should "throw NoSuchElementException if an empty stack is popped" in {
    val emptyStack = new Stack[Int]
    a [NoSuchElementException] should be thrownBy {
      emptyStack.pop()
    } 
  }
}

Cucumber test:

code:


    @Given("^There is a person$")
    public void There_is_a_person() throws Throwable {
        this.person = new Person(NAME);
    }

    @And("^it is (.*)weekend$")
    public void it_is_weekend(String isOrIsNotWeekend) throws Throwable {
        this.isWeekend = !(NOT.equals(isOrIsNotWeekend));
    }

    @When("^the alarm rings$")
    public void the_alarm_rings() throws Throwable {
        //TODO: make some irritating noise...
    }

    @Then("^the person should (.*)get up and go to work$")
    public void the_person_should_get_up_and_go_to_work(String isOrIsNotWeekend) throws Throwable {
        final String expectedMessage;
        if (NOT.equals(isOrIsNotWeekend)){
            expectedMessage = NAME + " goes to work!";
        }
        else {
            expectedMessage = NAME + " does not go to work!";
        }

        String actualMessage = this.person.goToWork(this.isWeekend);
        Assert.assertEquals(expectedMessage, actualMessage);
    }

# ? Nov 25, 2014 15:37

Above Our Own: Jun 24, 2009; by Shine

I guess this is more of a math question, but given date range (Start1, End1) and another date range (Start2, End2), is there a common pattern for calculating the number of days that the two ranges share if they overlap? I was just going to do it the dirty way and iterate through one of the ranges but there has to be a more elegant way.

(Not that it matters a whole lot, but I'm implementing this in javascript and using the moment time library if anyone has experience with that)

# ? Nov 25, 2014 16:10

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

min(End1, End2) - max(Start1, Start2)

Or am I horribly misunderstanding your problem?

# ? Nov 25, 2014 16:36

qntm: Jun 17, 2009

Above Our Own posted:

I guess this is more of a math question, but given date range (Start1, End1) and another date range (Start2, End2), is there a common pattern for calculating the number of days that the two ranges share if they overlap? I was just going to do it the dirty way and iterate through one of the ranges but there has to be a more elegant way.

(Not that it matters a whole lot, but I'm implementing this in javascript and using the moment time library if anyone has experience with that)

When you say "the number of days that the two ranges share" I'm going to go ahead and make some assumptions: that your ranges are inclusive-exclusive (e.g. "5 November 2014 to 5 November 2014" contains precisely zero days and "5 November 2014 to 6 November 2014" contains one), and that you're not crazy about time zones, daylight saving, or leap seconds.

JavaScript code:

/**
    Pass in four Date objects. Use this constructor:

        var start1 = new Date(Date.UTC(year, month, day));

    because JavaScript dates are in the current locale otherwise -_-
*/
function overlap(start1, end1, start2, end2) {
    start1 = start1.getTime();
    end1 = end1.getTime();
    start2 = start2.getTime();
    end2 = end2.getTime();
    
    var start3 = Math.max(start1, start2);
    var end3 = Math.min(end1, end2);

    // No overlap, or one or more ranges are disordered (`end` < `start`)?
    if(end3 < start3) {
        return 0;
    }

    var millisecondsPerDay = 1000 * 60 * 60 * 24;
    return (end3 - start3)/millisecondsPerDay;
}

var startOfYear      = new Date(Date.UTC(2013, 0,  1));
var middleOfYear     = new Date(Date.UTC(2013, 5, 30));
var endOfYear        = new Date(Date.UTC(2014, 0,  1));
var middleOfNextYear = new Date(Date.UTC(2014, 5, 30));

console.log(overlap(startOfYear, endOfYear,    startOfYear,  endOfYear));    // 365
console.log(overlap(startOfYear, endOfYear,    middleOfYear, endOfYear));    // 185
console.log(overlap(startOfYear, middleOfYear, middleOfYear, endOfYear));    // 0
console.log(overlap(startOfYear, endOfYear,    middleOfYear, middleOfYear)); // 0
console.log(overlap(endOfYear,   startOfYear,  startOfYear,  endOfYear));    // 0

# ? Nov 25, 2014 16:50

Above Our Own: Jun 24, 2009; by Shine

Thank you both, that clicks and seems very obvious in retrospect!

# ? Nov 25, 2014 20:22

Boz0r: Sep 7, 2006; The Rocketship in action.

Any recommendations for good books on software architecture and patterns and stuff?

# ? Nov 25, 2014 21:29

thegasman2000: Feb 12, 2005; Update my TFLC log? BOLLOCKS!
/

Yeah I figured it out!

# ? Nov 26, 2014 01:00

Hughmoris: Apr 21, 2007; Let's go to the abyss!

How would one go about creating a simple webpage with a text box, and that text box acts as a search field, and it searches a local folder that is full of files?

I want to gather all of the education material (PDFs and word docs) my team creates and place them in a single directory. That way, users can go to an intranet site and search for whatever education material they need. I'm just now sure how to get started on it.

# ? Nov 26, 2014 04:34

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 10:15

KoRMaK: Jul 31, 2012

Hughmoris posted:

How would one go about creating a simple webpage with a text box, and that text box acts as a search field, and it searches a local folder that is full of files?

I want to gather all of the education material (PDFs and word docs) my team creates and place them in a single directory. That way, users can go to an intranet site and search for whatever education material they need. I'm just now sure how to get started on it.

Ruby on Rails

# ? Nov 26, 2014 04:37

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ask General Programming Questions Not Worth Their Own Thread

«‹›671 »