image: Visual Studio 2017 configuration: Debug before_build: - nuget restore
Sunday, July 16, 2017
CI for C# projects: AppVeyor
I tried Travis CI for continuous integration of a C# WPF project and it failed because Travis CI uses Mono and that is not sufficent for WPF apps. So I tried AppVeyor and was successful. My minimalist appveyor.yml file is as follows:
Wednesday, July 12, 2017
Friday, July 07, 2017
Difference between novice and experienced engineers
It has been said that good/experienced software engineers can be several orders of magnitude (i.e. 10x-100x) more productive than novice engineers. I think the main productivity improvement is the fact that experienced engineers are much better at detecting/avoiding bullshit:
Nowadays, I am in my 20th year as an engineer. I pride myself in my analysis skills, ability to see signal through the noise and avoiding waste of resources. A lot of times I finish a job by demonstrating that the job in question is worthless/wrong. If you compare my lines of code per unit time, a novice might produce more. But that usually means producing garbage at a faster pace, creating more problems than solutions. That is why experienced people are worth their weight in gold.
It’s far more dangerous to assume people know what they’re talking about, than it is to assume they don’t and let them prove you wrong.When I was a fresh engineer, I naturally did the work given to me by other people, without questioning if it was worth doing. As I got more experienced, I realized that most of the time people don't have thought through the job they are assigning to others. This results in getting stuck in dead ends, doing things that have no importance which result in lost time and motivation.
Nowadays, I am in my 20th year as an engineer. I pride myself in my analysis skills, ability to see signal through the noise and avoiding waste of resources. A lot of times I finish a job by demonstrating that the job in question is worthless/wrong. If you compare my lines of code per unit time, a novice might produce more. But that usually means producing garbage at a faster pace, creating more problems than solutions. That is why experienced people are worth their weight in gold.
Saturday, July 01, 2017
Using Travis CI for Java Projects
When using Travis CI for automated testing / continuous integration of Java projects created with the NetBeans IDE you have to do the following:
- On NetBeans, Project/Properties/Sources make Source/Binary Format equal to JDK7. If you use JDK8, Travis CI ant will fail.
- You must have at least one JUnit test.
- You have to copy Junit and Hamcrest jars to project directory and add them under Libraries in NetBeans. If you leave them under Test Libraries, Travis CI won't be able to find them.
- Commit changes to GitHub.
- Add .travis.yml file to your github project root with the line language: java
- Go to Travis CI and sign in with your GitHub account.
- Click on your Travis CI profile picture / Accounts. Your open source GitHub projects will be listed.
- Enable your project for CI by clicking the button to its left.
- Click on the project to go to build page which kicks off build.
- If you have done everything correctly, you should see a success message at the end of the build page.
- To add the build banner on top of build page, click on the banner, select Markdown and copy the link.
- On your GitHub page, edit README.md, paste the link and commit.
Tuesday, June 20, 2017
JIRA for project finish time estimation
Software projects are notorious for their schedule overruns. One of the reasons is that project finish dates are usually based on wishful thinking, wich does not even make those dates nano-percent dates.
Herewith I propose a data driven approach using JIRA: The most important thing is to have enough issues in place to make statistical analysis meaningful, let's say at least 30 issues. After that, we need to make sure that we close issues faster than we create them. Only after we satisfy these two conditions can we talk about reasonable finish time estimations.
Below is my proposed project status page that updates whenever issues change, i.e. you do not need to ask people about when the project will finish or what the completion percentage is, it is all done instantly and automatically. The manager will always have up to date estimations. Only after your team has sufficient practice with this system should you worry about velocity/burndown etc. charts.
Calculation of parameters:
Enough issues = Total nb of issues > 30 ? Green : Red
Issues decreasing = (nb of closed issues in last 3 months) > (nb of created issues in last 3 months) ? Green : Red
Avg. nb of issues closed per month = (nb of issues closed) / (nb of months passed from project start)
Months required to finish project = (nb of open issues)/(avg. nb of issues closed per month)
Estimated finish date = Todays date + Months required to finish project
Estimated completion = (nb of closed issues) / (total nb of issues) *100
Herewith I propose a data driven approach using JIRA: The most important thing is to have enough issues in place to make statistical analysis meaningful, let's say at least 30 issues. After that, we need to make sure that we close issues faster than we create them. Only after we satisfy these two conditions can we talk about reasonable finish time estimations.
Below is my proposed project status page that updates whenever issues change, i.e. you do not need to ask people about when the project will finish or what the completion percentage is, it is all done instantly and automatically. The manager will always have up to date estimations. Only after your team has sufficient practice with this system should you worry about velocity/burndown etc. charts.
Calculation of parameters:
Enough issues = Total nb of issues > 30 ? Green : Red
Issues decreasing = (nb of closed issues in last 3 months) > (nb of created issues in last 3 months) ? Green : Red
Avg. nb of issues closed per month = (nb of issues closed) / (nb of months passed from project start)
Months required to finish project = (nb of open issues)/(avg. nb of issues closed per month)
Estimated finish date = Todays date + Months required to finish project
Estimated completion = (nb of closed issues) / (total nb of issues) *100
Wednesday, April 05, 2017
Modular design
The most important software design principle is separating the system into independent modules. By modules, I mean separately compilable units that can be "easily" unit tested. Benefits of modular software design:
- It will be harder to introduce unintentional side effects like
- Adding dependencies to code not related to the module.
- Delete code that is not related to the module.
- Modules can be designed separately which decreases mental load.
- Each module will have its own unit tests, when unit tests are run, not the whole project but only that module will be built.
- Each module will have its own string resource file instead of a giant resource file for the whole project.
- Bad design (usually due to inexperience, time pressure or plain laziness) will be limited to the module in question and won’t be a project wide cancer.
- There will be less merge problems.
- Portions that have higher security requirements can be dealt with locally in modules instead of affecting the whole code.
- Being able to test modules independently helps in identifying bugs like memory leaks.
- It will be easier to define and assign tasks to developers. As long as the inter-module interfaces are clearly defined, integration will be easy.
- It will be easier to estimate time and resource requirements.
- If will be easier to reuse the module in other projects.
- A module might be used standalone to do some tasks that does not require the whole system to be online.
- If MVC was used, desktop GUI can be quickly converted to web front end and logic can be used as back-end and the whole application can be converted to a web application.
Friday, March 31, 2017
Android client connecting to java server example
As a case study on how to use a VPS, I bought a VPS from Amazon LightSail, wrote a server in Java and a client in Android:
- I selected the preconfigured Ubuntu option. It has no GUI, you have to do everything on the command line.
- I created a static IP.
- In order to access it freely (ping etc.), go to networking tab, under firewall add “All TCP+UDP”
- On Ubuntu, I installed OpenJDK8:
- sudo apt-get update
- sudo apt-get install openjdk-8*
- I installed Putty to use as an SSH terminal
- I installed Filezilla for file transfers.
Server software:
Android client software:
TODO:
- Wrote server in Java on my laptop and transferred the code to VPS via FileZilla.
- I used gson for object-JSON conversions. The latest gson jar file can be downloaded from here.
- I wrote a java build script in Ubuntu using nano.
- Note that if you write the script in Windows and transfer it to Ubuntu, it might not work because line endings in Windows and Linux are different.
- To make the file executable: chmod
+x filename - I built and run the server. I prepared a shell script and ran it like so: ./script.sh
- To make sure that server keeps running when I disconnect putty, I used nohup and disown.
- Update 15.10.2017: To keep nodejs server running do the following:
- nodejs index.js> stdout.txt 2> stderr.txt &
- Do not close putty by clicking the top right "x", type exit.
- To kill a process
- Note PID by running ps -ef (or better, pgrep <process name>)
- Kill process with sudo kill PID
- Wrote client in Android Studio.
- I used gson for object-JSON conversions.
- I had to use AsyncTask for connection, otherwise I get NetworkOnMainThreadException
TODO:
- Server: Handle multiple simultaneous connection requests
Subscribe to:
Posts (Atom)


