Posts Tagged ‘programming’

Posted by Tatyana at 6 February 2012

Category: Dev, Java

Tags: , , , , , , , ,

Controllers in Spring MVC are desined to be shared between requests. Each controller has a default singleton scope so if you are using controllers you neeed to be aware of that. The easiest way to make sure your controller is thread-safe is to not to have class variables. F.ex. this example from Spring MVC tutorial:

@Controller
@RequestMapping("/editPet.do")
public class EditPetForm {

    private final Clinic clinic;

    public EditPetForm(Clinic clinic) {
        this.clinic = clinic;
    }

    @RequestMapping(method = RequestMethod.GET)
    public String setupForm(@RequestParam("petId") int petId, ModelMap model) {
        Pet pet = this.clinic.loadPet(petId);
        model.addAttribute("pet", pet);
        return "petForm";
    }

    @RequestMapping(method = RequestMethod.POST)
    public String processSubmit(
            @ModelAttribute("pet") Pet pet, BindingResult result, SessionStatus status) {

        new PetValidator().validate(pet, result);
        if (result.hasErrors()) {
            return "petForm";
        }
        else {
            this.clinic.storePet(pet);
            status.setComplete();
            return "redirect:owner.do?ownerId=" + pet.getOwner().getId();
        }
    }
}

In this example we can have a serious issue regarding thread-safety: private variable clinic. If there will be a situation where to different requests access the controller simultaniously, one of them will instanciate the controller and begin to process a form, then the other one comes inn. The result from processing of the first request will be sent to the other one, thus the requests receive fail data or nothing.

The solution to the problem may be the following:
1. Annotate Controller with @Scope(“request”) or @Scope(“session”)
2. Move private variable into one of the methods or save it in session or model.

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by Tatyana at 12 January 2012

Category: Dev, Java

Tags: , , , , ,

Well, maybe not in theory, but in practice – definitely.

Test-drive development is a way to program where you write an automated unit test that fails first, then you write code and check that the test runs ok. Brilliant theory for an ideal world (doesn’t exist). In practice however it is very seldom that you as a programmer have a full and clear understanding of what is it you are gonna do.

Of course I’m not talking about cases where you need to calculate the result of 2+2. Sure you can write a test case here.

And here comes a hard reality where you come to the real place, f.ex. a bank that needs a new program. And here you are with a task that states smth like this “Create a form that have these and these fields and calculates that and that”. You begin with a test case? You are right! That’s what happens if you do this: you kill several days  trying to understand how you build this test case, what fields you need to fill inn to calculate the result. If you’ll try to check a more specific result then you need several extra days to find a person who maybe knows how the value must be calculated.

Because it is very seldom in the real world that programmers work together with persons who both know and can explain to the programmer how the things should be done. Simply because those persons do not exist.

So you wrote the test and now you need to write a calculation algorithm… Hmm, how the hell do we do that? We start building it and magic happens! The algorithm that can calculate the value needs all totally different input values then those you’ve written in your test case… Ouch! It happened again?

At the end you’ve used double time to write the code and update the test case in parallel plus the time you’ve killed on the test at the beginning.

So why is it so popular to talk about it and constantly try to use it? Do not know. You need to write test cases when you program difficult logic. That is the fact. But doing it FIRST? It’s just a waste of time and killing of enthusiasm. You won’t be clever and you’ll not write better code if you kill time with the test first.

What really needs to be done before you start programming is to draw a solution.

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by kent at 9 March 2011

Category: Dev

Tags: , ,

From TDWTF.

Inept management hires inept arrogant conceited glory hogging twit

Inept management promotes twit at twit’s urging

Twit hires more twits for personal gain

Twit blames remaining competant workers for downward spiral

Remaining competant worker leaves

Company does well-deserved tail spin, crashes and burns

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by Tatyana at 28 February 2011

Category: Dev, Flex

Tags: , , , ,

<?xml version="1.0" encoding="utf-8"?>
<mx:DataGrid xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Script>
        <![CDATA[
            import mx.controls.Label;

            public function willShowResult(result:Label, myVar:String):Boolean {
                if (myVar== 'XXX') {
                    return false;
                }
                return true;
            }
        ]]>
    </mx:Script>

    <mx:columns>
        <mx:DataGridColumn
            dataField="myVar"
            headerText="My var"/>
        <mx:DataGridColumn
            dataField="result"
            headerText="My result">
            <mx:itemRenderer>
                <mx:Component>
                    <mx:Label text="{outerDocument.willShowResult(this, data.myVar) ? data.result : ' ' }"/>
                </mx:Component>
            </mx:itemRenderer>
        </mx:DataGridColumn>
    </mx:columns>

</mx:DataGrid>
VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by Tatyana at 28 February 2011

Category: Java, Tip

Tags: , , , ,

If an autocomplete stopped working go

Window -> Preferences -> Java -> Editor -> Content Assist -> Advanced ->  check for “Other Java Proposals”

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by Tatyana at 21 January 2011

Category:

Tags: , , , , , ,

I’ve been working in a scrum team for about two years from now and although it’s a good methodology to have things done, there are some issues with that that every leader must consider before using it.

Technology

Simple design
A scrum method forces tasks to be designed as simple as possible. An iteration that lasts 3 week cannot deliver more than there is capacity. That’s why tasks are divided in much smaller pieces and this gives everyone good picture of what is done and what is standing.

Refactoring
Refactoring is always an issue in software development. In case of scrum refactoring have seldom high priority. These leads to large and difficult to maintain software source code. Although when prioritized the refactoring is done quickly and effective.

Test-driven development
Correctly organized scrum process is always test-driven. It means that after each iteration the code is tested and eventually is sent back to a scrum team to fix bugs. It results in a code with minimal bugs when being presented to the customer.

Pair programming
Pair programming is a good and sometimes effective way to solve difficult tasks. Although it costs much and that’s why should be used carefully.

Continuous integration
Tools like continuous integration servers are a key to an effective and successful software development process especially when many people work together. It saves time and money when integrating pieces of software together.

People

Performance
Performance with a scrum method is rather high. That is the result of an iteration development. When a developer knows that he or she must show results at the end of the iteration they do what they need to to solve the problem in time. It doesn’t mean that everything a leader want will be done, but the most reasonable will be.

Motivation
When it comes to motivation so there are many factors that can motivate together with many other that can do the opposite job. The motivators in a scrum team are usually to have the work done, to show results to the customer, to receive a bonus for achieved results, to work together with other people and so on. But all these motivation points disappear when there are conflicts in a team or where the tasks are not as simple as scrum requires them. If you give a large scale task it means that the team cannot solve the problem within an iteration. And if a team do not see the results the members begin to miss the main motivation – to deliver.

Innovation
When it comes to innovation so there is nothing. It’s not possible to stress a team to deliver results and at the same time expect that they will work innovative. Innovation takes time.

Problem solving
Problems will be solved within an amount of time that an iteration lasts. You can’t expect the best solution to the problem. Here is a risk of solving problems in a way that creates more problems later.

Staff
Well. here is the main point. For the time I’ve worked in a scrum team (14 month) only 3 of 17 developers are still working here. It gives a staff change rate of 85%. If you think that this is normal – think again.

So where is welfare?
Definite not in a scrum team. And here are some of the reasons people don’t like it:
- you don’t have a feeling of having an ownership to the stuff you develop
- you see how easy other people take your place and your code
- you can’t do many errors because other people will come and get you for that
- constant competition that doesn’t stop for a minute
- your achievements are easy to forget because it’s not you that do the work i a scrum team – it’s a team! Nobody cares if it’s only you that do the work.

Should we use scrum?
Well, it’s a good methodology to have things done, but you as a leader must consider the following:

1. Do you have enough stuff on the market? Remember staff change rate of 85%!
2. Do you care about those who work for you today and don’t care if they leave you?
3. Do you have enough work for a whole team for a whole period?
4. Do your business depend on innovative thinking?

VN:F [1.9.13_1145]
Rating: 5.0/5 (3 votes cast)
Share

Posted by Tatyana at 17 October 2010

Category: Dev, Java

Tags: , , ,

It’s uncommon to see methods like this>

public Person findPerson() {
   if(someService) [
     return someService.getPerson();
   }
   return null;
}

There is no reason to make a Person object where there are no persons found. But doing so requires extra code in the client to handle the null value. This becomes a problem if a client is, for example, a GUI:

somePage.jsp
<%
  ...
  Person person = myService.findPerson();
%>
<table>
   <tr>
      <td>${person.name}</td>
      <td>${person.address}</td>
      <td>${person.numberOfPurchases}</td>
   </tr>
</table>

The result of such code in cases where the person cannot be found is Server error. So, there is no reason ever to return null from an object-valued method instead of returning an empty object. Especially if you deal with arrays and collections.

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by Tatyana at 14 October 2010

Category: Dev, Java

Tags: , ,

How many times we write a program like this:

public void doSmth() {
    Salary s = calculateSalary(Person p);
    ...
}

private Salary calculateSalary(Person p) {
   return 100;
}

And so we hear from our sjef that we can’t have same salary for male and female. So we do this:

public void doSmth() {
    Salary male = calculateSalary(Person p, true);
    Salary female = calculateSalary(Person p, false);
    ...
}

private Salary calculateSalary(Person p, boolean sex) {
   if(sex) return 100;
   else return 50;
}

Yes, but what if we have more options later on? Or if we look just at the doSmth() function? What do these true/false mean?

An enum type in such cases makes your code easier to read and to write, especially if you are using an IDE that supports autocomplition. Also, it makes it easy to add more options later.

So here’s how we should do it:

public enum Sex {MALE, FEMALE}

public void doSmth() {
    Salary male = calculateSalary(Person p, Sex.MALE);
    Salary female = calculateSalary(Person p, Sex.FEMALE);
    ...
}

private Salary calculateSalary(Person p, Sex sex) {
   if(sex.equals(Sex.MALE) return 100;
   else return 50;
}
VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by kent at 19 August 2010

Category: c++, Dev

Tags: , , , , ,

Okay. This is going to be somewhat personal.

I’m a professional software developer for a medium sized company, which is really not a software company. It’s only internal software I write.

I’ve also wanted to make a game since I started playing games. That’s probably why I’m a software developer today. I’ve been doing more or less C++ since I was 14, doing (at least trying to) 3D-graphics since I was 18. Without knowledge of the particular mathematics involved with 3D-graphics it proved to be difficult.

I’ve started numerous projects with OpenGL, and some are more advanced than others, but I didn’t continue working on a project for more than 2-3 days before I got tired.

I’ve started an other project now. I don’t know what I’ll make, or whether if I’ll make anything. But I’ve started an other project. The only real difference from previous projects is that I know the value of libraries and there is no point in re-inventing the wheel for every project.

Standard template library is there, Boost is there and some other libraries. I know how to use them. And I know they exist!

For this project I know I’m going to use

  • STL
  • The boost libraries
  • Ogre3D for graphics

I’m not so sure about the sound and physics part, but for now I think I’ll stick with

  • Bullet for physics
  • FMOD for sound

I must also review the licenses  for the libraries to make sure they are allowed to be used in commercial projects or not. I’m not saying my project is going to be commercial, but I won’t exclude it. I’ll also aim for Windows and Linux support. And probably Mac if it’s going to be commercial.

So far I have an empty scene with a blue background.

It’s a start! … again

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share

Posted by kent at 4 July 2010

Category: Memorable

Tags: ,

1. Painters need to start painting the interiors before the house foundation is started on.

2. Carpenters must finish the roof before the walls are strong enough to support it.

3. The exterior should look like gold, but in reality made of mud.

4. Skip the foundation. Nobody will ever care to take a look there, or have access there.

5. The electricity, water pipes and waste disposal can go through the same pipe.

6. When the house is almost finished, the owner wants to move a couple of walls, add some floors, at no extra cost.

7. When the house is “finished”, the owner must expect to patch it up when it rains, apply service personell monthly and within 2 years the house it out of date.

VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
Share