“This is a text.

This is another text.”

In database this text was stored as char(255) like “This is a text.\r\n\This is another text.”

Here is the original code:

<mx:TextArea id="commentInput" height="50" maxChars="255"
     text="{personModel.person.comment}" width="100%" tabIndex="20"/>

After some time I figured out that the reason the form was dirty was HTML text. So to fix it I changed text with htmlText:

<mx:TextArea id="commentInput" height="50" maxChars="255"
     htmlText="{personModel.person.comment}" width="100%" tabIndex="20"/>

But, this solution gave an unaxpected side effect. This was possible to render only one person, if I tried to render the other one in another tab, same data was visible for both persons.

That’s why I needed to solve the problem with replacing:

<mx:Script>
        <![CDATA[
        public function get comment():String {
            var crlf:String = String.fromCharCode(13, 10);
            var regEx:RegExp = new RegExp(crlf, "g");
            return _kommentar != null ? _kommentar.replace(regEx, "\r\r") : '';
        }
        ]]>
</mx:Script>
...
<mx:TextArea id="commentInput" height="50" maxChars="255"
     text="{personModel.person.comment}" width="100%" tabIndex="20"/>

No related posts.

The “broken window theory”

In inner cities, some buildings are beautiful and clean, while the others are rotting hulks. Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict [The police and neighborhood safety, James Q.Wilson and George Kelling].

One broken window, left unrepaired for any substantial lengt of time, instills in the inhabitants of the building a sense of abandonment – a sense that impowers to not to care about the building. So another window gets broken. People start littering and drawing graffiti. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and a sense of adandonment becomes a reality.

Don’t leave “broken windows” (bad designs, poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. In any case, take some action to prevent further damage and to show that you are on top of the situation.

[The pragmatic programmer, Andrew Hunt, David Thomas]

No related posts.

@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.

No related posts.

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.

No related posts.

No related posts.

Silly: Hi guys!
Silly: Here is the specification of you new task!
SPEC: We want a “Calculate” button that calculates when you push it.

No related posts.

Then enter following commands…

> bootstrap.sh
> bjam.exe --toolset=msvc --link=static --runtime-link=static --build-type=complete stage

No related posts.

<bean id="sessionFactory"
		class="my.class.MyEntitySessionFactory">
		<property name="hibernateProperties">
			<props>
				<prop key="hibernate.show_sql">true</prop>
			</props>
		</property>
		<property name="dataSource" ref="dbDataSource" />
</bean>

No related posts.

Core: How do I make Hibernate to not to retreive all objects at the same time?
Mag: Do i lazy.
Silly: Yeah, don’t work too hard!

No related posts.

Core: I HATE tests!
Tester: What?
Mag: He said he HATES TESTERS.

No related posts.