Search Results

Search found 6 results on 1 pages for 'finrod'.

Page 1/1 | 1 

• Office arangement - comfort vs. teamwork?

  - by finrod

  Our team works in an open-space office. Luckily the cubicles are quite big (L shaped tables for everyone!), there is quite a lot of space so we are not sandwiched. Without going into further detail, there are comfortable spots (window), normal spots and stupid spots (near the corridor). Until recently, the development team of twelve engineers was seated so that all types of spots were occupied and we were all close together. In the old arrangement, verbal communication was very easy - half of the team was withing talking distance. The other half was like ten steps away. Often times I could ask, discuss, solve problems without leaving the cube. Most of the communication is work related, no bullshit or mental masturbation that would unnecessarily distract others. Now we have moved to another part of the building and have larger space to occupy. At this point, everyone could pick their spot. Naturally all stupid spots are left empty (for the poor newcomers to occupy bwehaha). In the new arrangement, the development team is stretched across the floor and some of the key engineers are seated 'far' from each other - definitely not within talking distance. I have yet to experience how this works out but am getting concerned that team work and communication may have been traded for personal comfort. Finally the questions... What do you think is better office arrangement? Such that allows for free verbal communication but trading for some developer's comfort, or such that potentially hinders verbal communication but makes developer's more comfortable in their spot? Or maybe it does not matter at all and we will evolve to be efficient in any arrangement? What is your personal experience? Note - yes I read books and posts how workplace is important in our job. However in this case - we are all still in open space and the difference between the different spots are not really groundbreaking. So I'm thinking the little comfort that few developers gain is not worth the loss of easy communication.

  Read the article

• What actions to take when people leave the team?

  - by finrod

  Recently one of our key engineers resigned. This engineer has co-authored a major component of our application. We are not hitting Truck number yet though, but we're getting close :) Before the guy waltzes off, we want to take actions necessary to recover from this loss as smoothly as possible and eventually 'grow' the rest of the team to competently cover the parts he authored. More about the context: the domain the component covers and the code are no rocket science but still a lot of non-trivial stuff. Some team members can already cover a lot of this but those have a lot on their plates and we want to make sure every. (as I see it): Improve tests and test coverage - especially for the non-trivial stuff, Update high level documents, Document any 'funny stuff' the code does (we had to do some heavy duct-taping), Add / update code documentation - have everything with 'public' visibility documented. Finally the questions: What do you think are the actions to take in this situation? What have you done in such situations? What did or did not work well for you?

  Read the article

• JAXB boolean handling oddities and JSF

  - by finrod

  There is a known bug in JAXB: https://jaxb.dev.java.net/issues/show_bug.cgi?id=733 JAXB does not properly generate boolean field getters and setters, this bug is left unfixed for backwards compatibility. A JAXB plugin exists and will ensure that the following getters and setters for boolean fields are generated: setXXX(Boolean value) is generated getXXX() is generated If the boolean attribute specifies default value in the XSD, then getXXX() returns boolean, If the boolean attribute does not specify default in the XSD, then getXXX() returns Boolean. Problem: trying to edit/view the XXX field in a JSF component (such as checkbox) does not work - the component is disabled. I have not traced this in depth but the assumption (backed by the workaround below) is that JSF EL resolver (or whathaveyou) looks for Boolean getXXX() method and since it does not find it, the component is disabled. Workaround: If I change the getXXX() method to always return Boolean, then everything goes. Questions: What are your ideas to address this problem? Have I missed some customization for the boolean-getter JAXB plugin? Is it possible (does it make sense) to alter JSF resolver (or whathaveyou) so that if Boolean getXXX() is not found, it will fall back to boolean getXXX()? I would prefer not to manually intervene and change all the generated getXXX() methods to return Boolean instead of boolean.

  Read the article

• HyperJAXB and IDREFs

  - by finrod

  I have eventually managed to fiddle HyperJAXB so that when XSD has complexType A and this has an IDREF to complexType B, then HyperJAXB will generate @OneToOne JPA annotations between the the two generated entities. However now I'm facing another problem: the XSD has complex type X that can IDREF to either complex type Y or complex type Z. In the end, I need instance of complex type X contain reference to either instance of class Y or class Z. Do you have any wild ideas how can this be done without manual alterations to the generated classes? And at the same time to make sure these entities are marshalled to a correct XML? How about using the JAXB plugin that allows generating classes so that they implement a particular interface? Could that lead anywhere?

  Read the article

• Java Input/Output streams for unnamed pipes created in native code?

  - by finrod

  Is there a way to easily create Java Input/Output streams for unnamed pipes created in native code? Motivation: I need my own implementation of the Process class. The native code spawns me a new process with subprocess' IO streams redirected to unnamed pipes. Problem: The file descriptors for correct ends of those pipes make their way to Java. At this point I get stuck as I cannot create a new FileDescriptor which I could pass to FileInput/FileOutput stream. I have used reflection to get around the problem and got communication with a simple bouncer sub-process running. However I have a notion that it is not the cleanest way to go. Have you used this approach? Do you see any problems with this approach? (the platform will never change) Searching around the internets revealed similar solution using native code. Any thoughts before I dive into heavy testing of this approach are very welcome. I would like to give a shot to existing code before writing my own IO stream implementations... Thank you.

  Read the article

• Design and Implementation stories for one feature in SCRUM?

  - by finrod

  If I divide development of a particular feature into multiple stories: First one for a high level design of the feature, Based on first story I create other stories to develop the different stand-alone pieces that compose the feature, Does it mean I'm doing waterfall? Note: I am big time SCRUM novice.

  Read the article

1