Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Sean Corfield
    @seancorfield
    As a Clojurian, I rely on Boot (now, previously I relied on Leiningen), even when working with Java in my own projects.
    Matthew J. Clemente
    @mjclemente
    I’m working on standardizing some of our naming conventions. Within our services, we frequently have get( id ) and check( id ) methods. The former returns a populated bean, the latter a boolean. There may also be convenience methods, like getByName( name ) or getDraft( id ). Under the hood, they all utilize a private method, which returns the result of a query, based on the parameters. I’m trying to name that private method. I initially used getByProperty( id ), but it bothers me that the name doesn’t differentiate it from related public methods that return objects.
    So my question is, should that method name somehow indicate that it is private and that its return type is different?
    Matthew J. Clemente
    @mjclemente
    thinking out loud here, but I may go with something like readByProperty( args ) and establish the internal convention that get prefixes methods that return objects and read is for private methods that actually query for the data.
    Sean Corfield
    @seancorfield
    Sounds reasonable. FWIW, we have get... for an object and find... for an array of structs, and then get…Iterator for an IBO (multiple objects).
    We don’t have an internal private method because we essentially use the find… function passing the PK as the only property (and just taking the first element of the array as the data we need internally).
    Matthew J. Clemente
    @mjclemente
    ahh. I like find. Short and clear.
    and I suppose the find method wouldn’t need to be private… I’ll have to think about that a little more.
    Awesome. Thanks @seancorfield
    Sean Corfield
    @seancorfield
    For us, no, since we traffic in structs and arrays instead of query objects.
    Matthew J. Clemente
    @mjclemente
    yeah, the reason that it was private is because the query object isn’t allowed out of the service.
    it gets converted, to a struct/array, or pushed into an object
    Sean Corfield
    @seancorfield
    We have no query objects anywhere now. No queries are ever done by CFML in our system, so we always have arrays of structs :)
    Matthew J. Clemente
    @mjclemente
    yeah, I can’t say that I’m not jealous of that. But we’re taking it one step at a time. We’ll get there.
    Sean Corfield
    @seancorfield
    Aye, we moved one step at a time… the in-between times were painful :)
    Matthew J. Clemente
    @mjclemente
    true, but each step brings us to a place less painful than the one before. Taking the steps (converting the code) can certainly be exhausting. Such is life.
    Lampei
    @Lampei
    @seancorfield Thanks for that recommendation for Gradle. I'm loving it so far.
    I've successfully converted our dev builds from using the ant script plus ivy to a completely gradle build file. I know there's quite a few more tweaks I need to do it, but it's been a great start.
    I've added it to a Jenkins build job, added in PMD, jacoco (that was a little involved as I was doing something incorrectly which was causing me to get no coverage results), and FindBugs.
    If you don't mind, I do have a question about dependency management within the Java world (and using Gradle to overcome that).
    Lampei
    @Lampei
    I'm still relatively new to the Java world (outside of minor interactions from CF previously), but I feel like I have a pretty good understanding of how things should work :). The devs were contending that they wanted to get rid of the old Ivy file (which I'm fine with as I got the gradle file working instead) and said that they manage their jar files by just adding them to the project. Now, of course, this seems completely wrong to me and sounds like they just couldn't figure out how to handle the dependencies correctly that should be involved in their project and just decided "I'll just add the file I need to my libs directory" and remove the other file.
    Is there a reason that they would need to manage the jar files outside of the build script? Seems like that is the whole reason it is there, and smart people have created it that way and are (hopefully successfully) using it in their projects. I would imagine if things had been done incorrectly in how certain jar files were created initially or they weren't managing their dependencies correctly in their project that they may run into issues, but it seemed like they just were trying to blow smoke, but again, I could be completely off as I am new to this Java world.
    Sean Corfield
    @seancorfield
    3rd party library JAR files? Absolutely should be managed by the build system, not devs.
    By all means have a local managed repository but they should not be "part of the project" -- that's silly.
    Lampei
    @Lampei
    Ok, that's good to hear then. I don't mind being proved to be wrong about something, or incorrect in my assertion, as long as they're coming from a solid base. I'll continue driving towards them using the build script, which should make all of our lives easier. The other frustrating part now is the lack of drive on their part to have even looked into this type of solution previously. It's not like this is anything new, and it must have been painful to have to implement this manually in the past every time, and no one took the initiative to look into something to try to ease the process. And now having to convince people "hey this is a good idea...give it a try".