I always need to test.
Never do trust that anything will work. I always get this urge to test. I have absolutely no faith in theory. Practice makes perfect ... not theory.
Developing applications without the ability to test if the code is working is too much for me, it's like painting blindfolded having both your hands in casts.
Note to the tech staff and IT security staff: If you do not give developers full access to every resource that will be used(not actually the real thing but at least an accessible copy) than you will 100% get security breach because the code could not be tested under real conditions.
The testing is a very head on process that allows the developer to test most of the code for most visible bugs. If we cannot test that means we are back in the pre-PC era. Look at what we develop and do not forget that testing is one of the most important things in the current development methods. I for one write code fast and not always do it right, because it would take me an awful lot of time to write clean and bug free code without testing like in assembler or machine code for microcontrollers.
Monday, October 30, 2006
Friday, October 20, 2006
"There and back again" - NetBeans to Eclipse
As background to this post. I have been working with NetBeans since it was Forte for Java CE. So I am pretty much used to NetBeans.
Eclipse 3.1 was not compelling enough to switch from NetBeans. NetBeans 5.0 was a huge step, and Eclipse 3.1 was not the best thing to make the change. Eclipse 3.2 has one of the most tempting features fot the switch - Java Editor - witch is superbe. Code completion blows away any other editor(comapring IDEA, Eclipse and NetBeans).
Eclipse team is very proud of their incremental compiler - I personally see no pluses in it, since if the code is bloken incremental or non incremental compiler - both will not help in that case. Auto compile is not a bad thing,though.
In my experience everything other than Eclipse RCP and JDT is not as good as its presented. For example WST is just horrible. JSP editing is nowhere close to NetBeans one.
So the only logical thing is to mix NetBeans and Eclipse for web development(or use some of the commercial tools, but JSP formatting is still horrible and unreadable).
If anyone is wondering how to mix NetBeans and Eclipse here is how:
1. Create Eclipse workspace, and the project that you need
2. Create NetBeans project, and note NetBeans directory structure.
3. Ajust your Eclipse directory structure to match NetBeans one.
4. NetBeans keeps compiled files in a different directory(build), so in Eclipse set the output directory to build
And basically youre done.
NetBeans uses 100% Ant builds so you get pacakaged WAR EAR or JAR files, with no additional actions.
NetBeans is gaining on Eclipse quite fast, so I am very excited. The 2 OSS IDEs that complement each other pretty good.
Eclipse 3.1 was not compelling enough to switch from NetBeans. NetBeans 5.0 was a huge step, and Eclipse 3.1 was not the best thing to make the change. Eclipse 3.2 has one of the most tempting features fot the switch - Java Editor - witch is superbe. Code completion blows away any other editor(comapring IDEA, Eclipse and NetBeans).
Eclipse team is very proud of their incremental compiler - I personally see no pluses in it, since if the code is bloken incremental or non incremental compiler - both will not help in that case. Auto compile is not a bad thing,though.
In my experience everything other than Eclipse RCP and JDT is not as good as its presented. For example WST is just horrible. JSP editing is nowhere close to NetBeans one.
So the only logical thing is to mix NetBeans and Eclipse for web development(or use some of the commercial tools, but JSP formatting is still horrible and unreadable).
If anyone is wondering how to mix NetBeans and Eclipse here is how:
1. Create Eclipse workspace, and the project that you need
2. Create NetBeans project, and note NetBeans directory structure.
3. Ajust your Eclipse directory structure to match NetBeans one.
4. NetBeans keeps compiled files in a different directory(build), so in Eclipse set the output directory to build
And basically youre done.
NetBeans uses 100% Ant builds so you get pacakaged WAR EAR or JAR files, with no additional actions.
NetBeans is gaining on Eclipse quite fast, so I am very excited. The 2 OSS IDEs that complement each other pretty good.
Friday, October 13, 2006
JSTL and JSF
I do not get it. Sun has brought these two technologies how come are they not compatible, or even interchangeable?
There is nothing of JSTL in JSF and vice versa.
There is NO WAY to mix them in cooperative way. That is there is no way c:forEach may have h:commandLink’s or forms effectively.
There is a good thing that JSF is quite good on the component side, allthough there is some confusion with "rendered" for new developers.
There is nothing of JSTL in JSF and vice versa.
There is NO WAY to mix them in cooperative way. That is there is no way c:forEach may have h:commandLink’s or forms effectively.
There is a good thing that JSF is quite good on the component side, allthough there is some confusion with "rendered" for new developers.
Monday, October 09, 2006
PostgreSQL, FirebirdSQL and MySQL(subjective view)
(Disclaimer: I am a PostgreSQL fan, this is my subjective personal experience)
Had a interesting experience with 3 of these DBMS'es.
Needed to write an application that opperates on 7000000 row table.
Need was:
- querry the table
- calculate some data, based on the row data
- update that row
Platform Java 1.5. Latest versions, latest drivers. Containers transactional(1 MySQL run on MyISAM).
Methods:
a) Updateable resultSets
b) execution of update statements same trx
c) execution of update statements another trx
Funny observations:
In method a MySQL had no speed difference between InnoDB and MyISAM.
Method a on PostgreSQL was slower than method b
Firebird does not support updatable resultSets.
MySQL and PostgreSQL were on par in method b.
MySQL was 15% faster than PostgreSQL in method a.
Firebird was 25-50% slower, even on beter conditions(memory and priority).
Allthough Firebird required 50% less disk space.
Some versions of MySQL with MyISAM did: drop the changes, partial update on 1 row. InnoDB had no such problem.
There will be no conclusion to this post. All DBMS'es are evolving. I just hope that they do not stop.
-----
Based on a cooment I should add that most of the time taken up was waiting for update and select queries.
Data store should be a data store not an application.
Do not keep logic(except referential integirty and query simplification) on the DBMS side.
And in my example this was a telco billing application, so it was impossible to put all logic into the DB.
Had a interesting experience with 3 of these DBMS'es.
Needed to write an application that opperates on 7000000 row table.
Need was:
- querry the table
- calculate some data, based on the row data
- update that row
Platform Java 1.5. Latest versions, latest drivers. Containers transactional(1 MySQL run on MyISAM).
Methods:
a) Updateable resultSets
b) execution of update statements same trx
c) execution of update statements another trx
Funny observations:
In method a MySQL had no speed difference between InnoDB and MyISAM.
Method a on PostgreSQL was slower than method b
Firebird does not support updatable resultSets.
MySQL and PostgreSQL were on par in method b.
MySQL was 15% faster than PostgreSQL in method a.
Firebird was 25-50% slower, even on beter conditions(memory and priority).
Allthough Firebird required 50% less disk space.
Some versions of MySQL with MyISAM did: drop the changes, partial update on 1 row. InnoDB had no such problem.
There will be no conclusion to this post. All DBMS'es are evolving. I just hope that they do not stop.
-----
Based on a cooment I should add that most of the time taken up was waiting for update and select queries.
Data store should be a data store not an application.
Do not keep logic(except referential integirty and query simplification) on the DBMS side.
And in my example this was a telco billing application, so it was impossible to put all logic into the DB.
JSF Naming
I have been working with JSF for several months and would like to know what are the best/most used naming strategies for JSF backing beans.
Personal opinion:
Adding Bean at the end seams not reflecting the function of the component. (Do you agree?)
What do you think is the best naming?
Is it based on the part of the view? (SearchHeader, MenuForm, UserLoginBox)
View itself? (SearchView, EditView)
Activity? (Recorder, Editor, Viewer)
Any other naming conversion?
Personal opinion:
Adding Bean at the end seams not reflecting the function of the component. (Do you agree?)
What do you think is the best naming?
Is it based on the part of the view? (SearchHeader, MenuForm, UserLoginBox)
View itself? (SearchView, EditView)
Activity? (Recorder, Editor, Viewer)
Any other naming conversion?
Control over code
I do not know how you like, but I like to know what my code is doing.
Memory and very low leve stuff may be ommited but when it comes to ORM its a different story. SQL is NOT low level.
Sometimes I want to control what queries my ORM tool sends to my SQL server.
But there we hit a snag. Its either all or nothing. Hibernate or iBatis are completely different, one you have the freedom of not writting all queries yourself other is having full control over the queries.
Map anything to nothing (iBatis approach)
iBatis offers the luxury of mapping object to essentialy nonexistent entity. Be it a function/procedure call or a complex view(excluding updatable views). But iBatis(SQLMaps to be exact) is like flying an airplane. If you cant ir will stay grounded, if you can it will fly. A lot of queries and no descent generator.
Map something to something(Hibernate approach)
Anything can be autogenerated! Simplicity at it's best. Problem is if you have a table or a view you can map it, otherwise no way. JPA is very similar to Hibernate, excluding annotations(but lets not forget that XDoclet existed for quite a long time).
Problem is that there is a need for only a part of anything2nothing and a lot of something2something. That is why iBatis is not the best choise*.
So what was I searching for I what I did not find:
- simplicity for stuff like "category table with ID and NAME fields"
- control like use this query to get that data
- function/procedure mapping
- ability to specify whitch query should be used for what
But fortunatelly we have JDBC 4.0 on our horisons. iBatis will probably cease to exist due to similarity in its functionality to JDBC 4.0 DataSet. But iBatis and Hibernate still have powerful query construction languages(dynamic query construction in iBatis and HQL in Hibernate) .
So my problem still persists, since we cannot easily mix those 2 methods together.
* - to be exact iBatis can have Hibernate as its base instead of SQL maps, but different managers are required if you need to mix them.
Memory and very low leve stuff may be ommited but when it comes to ORM its a different story. SQL is NOT low level.
Sometimes I want to control what queries my ORM tool sends to my SQL server.
But there we hit a snag. Its either all or nothing. Hibernate or iBatis are completely different, one you have the freedom of not writting all queries yourself other is having full control over the queries.
Map anything to nothing (iBatis approach)
iBatis offers the luxury of mapping object to essentialy nonexistent entity. Be it a function/procedure call or a complex view(excluding updatable views). But iBatis(SQLMaps to be exact) is like flying an airplane. If you cant ir will stay grounded, if you can it will fly. A lot of queries and no descent generator.
Map something to something(Hibernate approach)
Anything can be autogenerated! Simplicity at it's best. Problem is if you have a table or a view you can map it, otherwise no way. JPA is very similar to Hibernate, excluding annotations(but lets not forget that XDoclet existed for quite a long time).
Problem is that there is a need for only a part of anything2nothing and a lot of something2something. That is why iBatis is not the best choise*.
So what was I searching for I what I did not find:
- simplicity for stuff like "category table with ID and NAME fields"
- control like use this query to get that data
- function/procedure mapping
- ability to specify whitch query should be used for what
But fortunatelly we have JDBC 4.0 on our horisons. iBatis will probably cease to exist due to similarity in its functionality to JDBC 4.0 DataSet. But iBatis and Hibernate still have powerful query construction languages(dynamic query construction in iBatis and HQL in Hibernate) .
So my problem still persists, since we cannot easily mix those 2 methods together.
* - to be exact iBatis can have Hibernate as its base instead of SQL maps, but different managers are required if you need to mix them.
Subscribe to:
Posts (Atom)
