Education from VSB university and industry point of view

IT Cluster meeting took place in Ostrava on 26th of September 2011. The meeting has been organized by VSB Technical university Ostrava. If I have got it right, then the participants are only the members of IT Cluster (have a look at them if you wish).
The main target of the meeting was to present what the university teaches and what is the feedback from software companies. Well, it is obvious that some courses are not set according to the needs of industry. As I have been told, that the meeting has been organized as a reaction to my blog post dedicated to VSB graduates. It was kind of my feedback on university graduates I have gathered during over hundred interviews with VSB graduates - have a look here. That is quite flattering, but nonetheless - this is great sign of reflection shown by the university. The university is finally trying to find out what are the industry needs - it is definitely good step forward and I am looking forward to be part of that journey. I should also note that the university has changed the curriculum already and we might see the output in few years (but I don't know what exactly has been changed so hard to predict what we might expect).

Nowadays, I am wondering...

Who is making the curriculum for the semesters and what the creation process is based on? 

It seems there are few areas of subject "Information technologies". Would it be possible to split it to these areas? So students could choose what suits them best? Some people will be never good developers or good testers (and so on...). The areas might be: 

1. software development (web based, mobile devices...) 
2. analysts
3. project management 
4. testing 
5. networking 

The university graduates with bachelor's degree should be able to start work in software company. This can be (and usually is) difficult because they have got no practice - so they don't have the behaviour/soft skills and the knowledge that is mandatory. How to give them a change to work in a software company? Student practice is really great for that, but it seems that there are not enough companies to provide that to all students... so the question is how to do that? 

Two semesters are dedicated to Algorithms and only one to Java and C# (C# is actually planned for two semesters). I am really wondering, is it really good to teach them C++, C# and Java? I am pretty sure that if developer is great in one language - he can learn the other easily. So, why don't teach them only one language? If they learn Java SE, Java EE, something about JVM and some top frameworks (to cover ORM, MVC...) then I am sure their price will go up and companies will be more interested in hiring the university graduates. Of course the choice must be based on their own decision, so student decides what language to master. 

The university is teaching also RUP, SCRUM - and I am wondering how they are doing that... how they are simulating supplier / customer environment, are there demo presentations, retrospectives and other key artefacts from agile? 

What about code quality and continues integration - it is pretty hard to make quality product without these things... Is this included in lessons?

There will be other meeting next week (4.10.2011) to discuss all the stuff more practically and agree on concrete steps - I think I am ready after writing this down :-) As I have already said, I am looking forward! 

How to add Vaadin Add-on into Grails project

Here is the new version of this tutorial for Vaadin 7: .../vaadin-7-and-grails-how-to-compile.html

---

I have spent quite a while by integrating Grails and Vaadin Add-on (I decided to use invient-charts). There are many things one has to do in order to get it working. The reason is that support of Vaadin Add-ons is not yet supported by Grails Vaadin plugin...

Versions: Vaadin plugin 1.4, Vaadin: 6.5.1, Grails 1.3.7

1. Eclipse and GRails plugin - use this tutorial to get it work http://grails.org/STS+Integration 
2. Create a GRails project (in this tutorial named "your-project") in Eclipse 
3. Install Vaadin plugin http://www.grails.org/plugin/vaadin 
4. Download and copy paste jar file into the lib folder: /your-project/lib/invientcharts-0.8.4.jar and add it to Java Build Path in Eclipse
5. Add this folder to Build Path /your-project/grails-app/vaadin 
6. Create your package structure and create widgetset configuration file: /your-project/grails-app/vaadin/com/yourproject/ui/vaadin/YourProjectWidgetset.gwt.xml
7. Add the widgetset set to /your-project/grails-app/conf/VaadinConfig.groovy 
   vaadin {
       // ...
       widgetset = "com.yourproject.ui.vaadin.YourProjectWidgetset"
   }
8. You have to update the creation of Vaadin page - because you want to use custom JavaScript (so you have to force Vaadin plugin to add it there) - as described in next step. Add the following code into this class: /your-project/.link_to_grails_plugins/vaadin-1.4/src/java/com/vaadin/terminal/gwt/server/GrailsAwareApplicationServlet.java. If you are using GAE, update the another class with GAE text in it's name.
   @Override
   protected void writeAjaxPageHtmlVaadinScripts(Window window, String themeName, Application application, BufferedWriter page, String appUrl, String themeUri, String appId, HttpServletRequest request) throws ServletException, IOException {
     super.writeAjaxPageHtmlVaadinScripts(window, themeName, application, page, appUrl, themeUri, appId, request);
     page.write("<script type=\"text/javascript\">\n");
     page.write("//<![CDATA[\n");
     page.write("document.write(\"<script language='javascript' src='VAADIN/jquery/jquery-1.4.4.min.js'><\\/script>\");\n");
     page.write("document.write(\"<script language='javascript' src='VAADIN/js/highcharts.js'><\\/script>\");\n");
     page.write("document.write(\"<script language='javascript' src='VAADIN/js/modules/exporting.js'><\\/script>\");\n");
     page.write("//]]>\n</script>\n");
   }
9. Upload JavaScript from invient-chart package 
1. /your-project/web-app/VAADIN/jquery/jquery-1.4.4.min.js 
2. /your-project/web-app/VAADIN/js/highcharts.js + sub folders
10. Compile the widget set (you have to use Ant because this is not supported by Vaadin plugin). Here is the file which must be modified (just go though and fill in missing parts or upload needed jars to "lib" folder). In case you don't know what version of gwt-user.jar and gwt-dev.jar you should use, check the release notes for your version of Vaadin:  http://vaadin.com/download/release/6.5/6.5.1/release-notes.html (you can download these jars from:  http://code.google.com/webtoolkit/versions.html) 
11. One more thing, I am not 100% sure - but when you run "clean" then you have to update GrailsAwareApplicationServlet file again (it happens to me quite offten).

I hope that my notes helped you. If you have any questions, just ask me and I will try to provide an answer. 

TextLab for Mac

Ultimate application to validate, clean and format JSON, XML, SQL, HTML.

Feedback on the university graduates

First of all, this is not criticism of university or students! This is meant as a feedback one might benefit from. 

Why do I want to give a feedback on university graduates?

Well, I am working in quite big company (Tieto) and a lot of students (mainly from VSB Ostrava) want to work there. I am responsible for hiring Java developers for our unit. I have done more than 100 interviews. It took me more than one year of interviewing. I am trying to find out what applicants know and if they are capable to join our teams. I have gather a feedback on what are the applicants weakest areas. 

Team work 

1. They don't know how to...
1. work in a team (because they don't have the experience).  
2. share the source code.
3. properly plan / divide work tasks.

Project set-up (from technical point of view)

1. They don't... 
1. know how to set-up project in IDE using Maven. 
2. know about code quality and code checkers. 
3. understand to the importance of javadoc. 
4. know what is the continuous integration. 
5. understand to usage of automatic testing (JUnit + Mocking) 

Modelling and Software engineering

1. They don't... 
1. know why it is important to draw class diagrams. 
2. know how to make class diagrams from requirements. 
3. know how to implement the class diagram! 
4. have any experience with usage of the design patterns, so they don't see the difference between using and not using the design patterns.

English skills

1. Most of the graduates are saying "English on the school is very poor and it gave me nothing". 

Here is my message to the students who want to be code developers. 

• Your teachers in the school can show you the way and explain the basics. The rest is up to you! Don't relay only on what the school teaches - be active and take the responsibility for career life.
• You must get the experience. There are many ways how to get it. For example: join open source projects, create your own project, work in a company or work on a project with other students. 

Resource & Material vs Agile approach

What is wrong with Resource & Material approach?

Resource & Material approach is when customer pays for the resources working on the project and the invoices for travelling and similar stuff. 

Imagine you are the customer. Why you should accept paying your supplier for the people working on the project? I think you want to pay for the implemented features not for the people working on the project. It means you want to have it done so it can help you to solve your problems. 

The customer takes the big risk of loosing money by accepting Resource & Material approach.  

The supplier takes the big risk of closing down the business for the low customer satisfaction. 

What is good on the Agile approach?

The realization team must be committed to deliver what the customer needs while working in the agile approach. The commitment must be done for short time period, not for years.

The customer says what he wants to deliver in an upcoming time period. This gives customer good control and overview of the process. And the realization team can be sure that are doing the right stuff.  

Let's sum it up.

Don't be naive and plan work for few weeks, not years. Require realization team to commit to deliver something what is giving you a value at the end of each time period. 

Agile or Fixgile?!

Have you ever heard about Fixgile [fixdʒaɪl]? No?!?! Don't worry, me either. Actually nobody could... because we came up with this name during creation of an offer for a customer who is not yet ready for agile.

When you are running in Fixgile?

You have experience with agile approach and you are not capable to accept fixed price/waterfall models.

You insert many items from the agile approach into the fixed price offer (but some the key ones are replaced by fixed stuff).

You want to use agile approach in your project but your customer is not ready for it and therefore not accepting it. 

How Fixgile looks like?

Specification (both system/functional and technical) is created beforehand. 

Testing is running together with development. 

Project is running in iterations (getting feedback by customer, doing demo presentations...) 

Test cases are created at the beginning of development. 

You divide all the required scope into the small pieces - so you create contract for each small part (way to mitigate big commitment at the begging). 

Customer is pushing you to estimate more work and commit your team for bigger scope (sometimes you are lucky, sometimes not).  

Is Fixgile good?

Sure! We all (suppliers & customers) are learning all the time and it is necessary to gain experience and knowledge somewhere. I believe it is the first step towards the agile approach and more happy customers and suppliers. 

What is the problem with agile approach and contracts?

I have decided to write down something about agile approach and its implementation in software companies. First of all, you are not alone in this world. You have your company, people around you and there are always your customers. 

I work in software company and it happens every now and then that customers are actually saying how to deliver the software product. How is that possible? Customer is usually saying how the contract should look like. Customer knows: what money he can spend, what must be delivered and when it should be delivered. 

Well, that is quite heavy stuff. Let's analyse is a bit...

"Customer knows what money he can spend" - this is absolutely fine, budget is clear - so customer knows what is the investment for the software development of contrived software product. The question related to this sentence is - "Does customer know if the reserved budget is enough for what they need?". 

 "Customer knows what must be delivered" - the question is, how he knows what should be delivered? How the information is passed to you? If it is a functional specification - it won't work. The functional specification is never 100% ready and correct. Let's say a customer has got enough money for a little experiment. The customer creates the functional specification and write there all the features of the requested product. Then the company passes this functional specification to 3 different software companies. What do you think, will they produce the same product? Is it exactly what customer expects? Can he use it immediately? Well, you could say "It depends on how the functional specification is written, is it detailed enough?". I can answer, yes - the customer did great specification with all needed details. There is written exactly what the company needs. So what is the problem with this? It is just because we are human and everyone interprets written text differently. We can use the example with sentence "Mary had a little lamb" - well, had Mary little lamb for dinner, or had she a little lamb in the yard (or there is also some interpretation that is available only for adults). 

"Customer knows when it should be delivered" - the start date is clear. The customer knows when they should go into the production. Does customer know what features are really needed? Is there enough time to implement those features? Or can we use prioritization and define scope (needed features) according to the priorities? 

It seems, that we have to deliver something uncertain for certain money and time. It looks good. But how to write it down? How to create agile contract? How to help our customer with understanding of agile approach? 

So, if you want to over talk your customers and convince them to sign the agile contract, you have to know and have good experience with agile development. It is really not easy to convince the customer. You have to be able to explain advantages of agile approach and disadvantages of waterfall or fixed price approach. What is the core of agile approach? What they will get more (when you compare it to your competitors)? 

What is the agile contract about? You commit your team to deliver exactly what customer needs based on their priorities. First of all, you have to be able to help them with prioritization process. Just don't ask - what is the highest priority for you... Go around a bit, ask them what part of the application they use most often. What is the core of the application. What are the users' complains... and so on. You can also estimate what budget you will spend and when something what is useful and gives some value to the customer will be delivered. 

You can't over talk customer just by words, you have to have the experience and some good examples. It is good to show success story - look at this project, they had all the problems and we solved them by agile contract.

Let me say one example. You are the person that should make the proposal to customer. You have got some functional specification, so you somehow know what should be delivered. But you don't know what exactly should be delivered. Why? Because it would take you months to understand to business logic of the application. So you decide to create something like agile contract where will be written "We are committed to deliver what is needed based on customer's priorities. The maximal price for the delivery is 2M euro and 20.12.2013 is the end of the development". Deadline is given by customer and you know that your team has 10 members (so you have calculated the price and it is about 2M euro). Then you define some rules like "Customer will support development team; Test cases will be created together with customer; Customer will participate each demo presentation and development team will get direct feedback on what has been delivered; Acceptance criteria are ...". Good job, it is done. You go to your manager and you know that pass this level will be quite difficult. He will ask you few questions, you answer something like "Well, we don't know what exactly is needed - so we offer something more like cooperation on the software product then just coding according to documentation.". OK, you have passed this one. Then you manager or you go to sales guy - the guy who should sell your proposal to the customer. Can you imagine what is the end of this story? Usually, sales guys don't have experience with agile approach. Sales guy want to offer customer with something more specific. He wants to offer: this and this will be delivered, this is the price and here is the time table - so he wants to know exactly what money (and when) will flow to your company. If you have survived this, go for a beer with friends and relax a bit. You are back in waterfall and fixed price project. 

The main preconditions - all people in the company have to have the right mindset. They have to be poisoned by agile approach.

Keep trying, don't give it up.

User group leader meeting (Prague 2011)

Oracle has organized great event, where leaders of Java and Oracle user groups could meet, see each other, discuss how to cooperate in future and what support we can get from Oracle.

We (Ostrava JUG) are quite new user group which is just starting up. So we have got some experience already but not that much as other user groups or conference gurus. For example Stephan Janssen (organizing Devoxx), Antonio Goncalves (founder of JUG in France), Radoslaw Holewa (organizing GeeCON), Martijn Verburg (London JUG) and other successful leaders.

We have discussed many various things and here are some that impressed me most. Great idea is to use Twitter during conferences or user group sessions. You can use it for questions, feedback and promotion. 

Use visibletweets.com during breakes (not during presentations, it can be difficult for speaker). It is a good practice to create special twitter account for conference and connect twitter with Facebook and LinkedIn.

We could also organize phone calls (something like 1 hour and 1 topic) - Oracle can provide conferencing enviroment (phone numbers...).

I really liked lightning talks we did during the meeting. I hope that we will do it also on our JUG.

Oracle announced lunch of Java SE 7 and it is scheduled for July 7th 2011. JUGs will receive funding, speakers and launch kit. That is just great!

I am full of ideas how to improve organizing of Ostrava JUG. Big thanks to all participants!

rework

I just read great book named Rework by Jason Fried and David Heinemeier Hansson (from 37signals company). There are quite strong ideas and it forced me to read it over and pick up ideas that impressed me most.

I would really appreciate discussion related to any item from this list. I personally do hope that I will come back to this list again and again in future :-)

1. Ignore real word and sentences like "it would never work in reality" as reaction on fresh idea.
2. Learning from mistakes is overrated.
3. Planning is guessing. This is where we are going because, well, that is what we said we are going to.
4. Growth is sometimes useless and not a good target, hire after strong reconsideration.
5. Workaholic does work for work, not for done work.
6. Enough with "entrepreneur", do what you love, be starter.
7. To do great work you need to feel that you are making difference.
8. The best and easiest way to make successful business or service is to make something you what to use.
9. Start making something.
10. No time is no excuse.
11. As you get going, keep in mind why you are doing it and what you are doing.
12. Strong stand is how to attract superfans. Stand for it and don't make stupid slogans.
13. When making something, don't ask where are the money coming from, it is too early.
14. Maybe you need less than it seems, it doesn't have to be right now.
15. Startup sucks, get business going and money flowing.
16. Exit strategy is for losers.
17. You are small and agile producer, use it well. Don't try to be big just for sake of it.
18. Less is good thing, constrains can make it better.
19. It is better to have half of product than nothing.
20. Start from epicenter (if I leave this, I am able to sell it still?).
21. Ignore details early on. Start with details when it is required, after implementation starts.
22. Decisions are progress. Switch from "let's think about it" to "let decide on it".
23. Be curator, remove, simplify and streamline what is not needed.
24. Reduce menu (as in great restaurants), do less, do it in great way.
25. Focus on what won't change (user-friendly software... and so on).
26. Tone is in your fingers.
27. Sell your by-products (IBM their processes... and so on).
28. Lunch it now, don't wait for 100% ready state, you can publish not finished versions.
29. Too much of specification makes illusion of agreement.
30. Reasons to quite: "Why are you doing it?", "What problem are you solving?", "Is this actually useful?", "Are you adding value?", "Is it going to change something?", "Is there an easier way?", "What could you be doing instead?", "Is it really worth it?".
31. Interruption is enemy of productivity.
32. Meeting are toxic: they are not real things, just words. Drift off-subject easier. Require preparation which is not done. Vague agendas. There is usually one who waste others time. one meeting leads to another. How to do it? Begin with clear agenda, set time frame, start with specific problem, invite less people as possible. End up with solution, setup responsibilities.
33. Good enough is fine, don't complicate it. Quick wins.
34. You can easily quit when you are small.
35. Go to sleep.
36. Your estimates suck.
37. Long task lists don't get done.
38. Take tiny decisions, big ones are hard to change and make.
39. Don't copy other's ideas. They make rules, you can win. Make it in your way.
40. If you think your competitors sucks, say it so. ;~)
41. You don't have to make more then your competitors, do less and do it your way.
42. Do what do you want to use, you need and know.
43. Lear and get used to saying "no".
44. Teach your customers.
45. Ideas give you rush, write it down, gave it some time and thinking.
46. Build an audience.
47. Show a backstage, people will be interested.
48. Publish on small web pages, The Times is not for you right now.
49. Drug dealers got it right, give some for free, they will come back with money in hands.
50. Marketing is in everything you do.
51. Overnight sensation doesn't exists, hard work is needed.
52. Hiring do it your self firs and hire when it hurts.
53. Great people are everywhere.
54. A lot of new people makes "cocktail party strangers" effect in your company.
55. Everyone has to work, delegators are not the right option usually.
56. Everyone should be able to manage him self, to act without company targets setting. Don't wait for somebody, get it done (as you get paid...).
57. Speed changes everything, quick response from support makes "atmosphere of care".
58. Culture is long term thing, it can't be build in while.
59. Stupid words when dealing about new business: need, can't, easy, fast.
60. Inspiration is perishable.