Search

Freitag, 22. Dezember 2017

End of 2017 but still problems with surefire plugin

Well i am once again amazed how some maven tools are unstable especially if you think that we nearing the end of 2017 , but still maven surefire plugin isn't stable for Junit 5!
If you like me  and you want spent little time in xml configuration here you go 100% working xml file with support of Junit 5 and tested with surefire plugin!

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.learningDesign</groupId>
<artifactId>ExampleOfLearningDesignPattern</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>Exercise1 of Design patterns</name>
<description>Exercise1 of Design patterns</description>

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<packaging>jar</packaging>

<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.0.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.0.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<version>4.12.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-launcher</artifactId>
<version>1.0.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-surefire-provider</artifactId>
<version>1.0.1</version>
<scope>test</scope>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>

<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<dependencies>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-surefire-provider</artifactId>
<version>1.0.1</version>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.0.1</version>
</dependency>
</dependencies>
<configuration>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</build>
</project>

Mittwoch, 13. Dezember 2017

Eclipse workaround for small size of icons!!!

Well finally i found a way to increase the size of icons in eclipse!



It was so simple just edit eclipse.ini  and add the line -Dswt.autoScale=150 after -vmargs !!!
I wonder why in the world Eclipse developers don't think about some plugin or feature which give you a optimal solution (some tool) for that kind of problem, well this works for me!


Sonntag, 10. Dezember 2017

First example of working Cobol program.


I am very puzzled how people programmed back in 60-70, it was probably very difficult task, anyway due to demand and luck of Cobol programmers on German market, i must achieve mastery with this language.
Here what i use to master Cobol jungle:

OpenCobolIDE - very good IDE for writing Cobol programs.
Cygwin and compiled Cobol ver. 2.2 just for debugging purposes!

The online tutorials which i do is from Lynda, well in this case they are the best , Pluralsight was too short and too complicated to master, but i done it anyway!!
So for you consideration here is a code which wrote, yes i can post it on github but i am kind of lazy today!


I like how IDE highlight the Cobol code , very good.
Syntax of this language is very strict you must watch out on which column you write and the length of variables is limited.
I don't like the way how datatype in Cobol declared it pushes a programmer to learn this cryptic and obscure Cobol format , which i already hate.
Here is the whole logic of the program, Cobol allows you to use operators (+,*,= and etc) but you must write first the word COMPUTE, in my opinion it doesn't make any sense why the Cobol authors done such bad job?? (rhetorical question)


If you asked me , what i would prefer if i had only choice between C and Cobol, well i would pick C language without any further thinking , just because C syntax is  a lot better then Cobol!!!!
We have huge problem developers, there are tons of Cobol code for enterprise critical applications, i don't care what you boss say to you , but i think developers who work with Cobol commercial projects must push forward and port Cobol code into other language like for example Java and C# (.Net) . 
Sure it's not so easy and i understand that there a lot of datatype inconsistency between Cobol and other languages, but we are responsible for our code like Uncle Bob said, clean your mess and do care about the code which you write or refactor! 
Another question arise , how can i test this code , is there any unit type testing possible?`I feel people who have a lot of experience with Cobol can test the code in their brains, but i think i must found a way to unit test this programming language even if take my all free time, this is very important if i wish to stay true to the clean code philosophy.
I will further learn "funny" things about Cobol language and will master it, but i will be very liberal of maintaining the Cobol Code. This means i am advocate of change , if somebody has a fear about loosing job and don't wish to change the current state of Cobol projects, then i will be the person on to which management can fire upon, i don't care really! My concern would be a quality of code, understanding the client request and ability to refactor the code in any cases, this my personal goal for the next year :-) 

Sonntag, 3. Dezember 2017

Cobol ist wieder im Trend.

Cobol ist sehr  alte Programmiersprache , welche bei den IBM Mainframe's für die Business Anwendungen Millionenfach verwendet wird.
Einer meiner Kunden hat mich sogar gebeten und aufgefordert diese Sprache zu lernen, na ja wenn man dafür gut bezahlt wird Ich bin immer bei solche Situationen dafür und bin sehr Abenteuerlich :)
Hier ist ein sehr kleines Beispiel von Cobol:

       IDENTIFICATION DIVISION.
            PROGRAM-ID. HALLOWELT.
            PROCEDURE DIVISION.
            DISPLAY "Hallo Welt".
            STOP RUN.

       END PROGRAM HALLOWELT.

Nach meinem Geschmack ist die Sprache sehr Zähe und bei komplexen Logik kaum so einfach zu verstehen, wenn Ich die Wahl hätte Ich für  C Sprache eindeutig entschieden da es einfach besser wenn man die beiden Programmiersprachen vergleich kann.
Ich kann mir kaum die Komplexität bei den älteren Cobol Anwendung vorstellen, eins ist aber sicher jemand muss diese Sprache verstehen und dann später in der Lage sein auf neue Programmiersprache zu portieren, wobei , dass ist auch ein Problem da in Cobol keine Lokal Scope gibt!

Man muss auch auf Typsicherheit bei Cobol aufpassen (ist dass überhaupt  möglich ?).
Für mich die Frage wird sich während des Lernens ergeben (ca. 6 Monate in Teilzeit).
Zu der Cobol Frage , kommt die Frage ob man die Mainframe von heutzutage kennen braucht, ich würde sagen Ja , heutzutage an der Uni man kommt so selten zu den Mainframes Technologie .
Mein Appel an die Firmen: sorgen Sie für die Nachwuchs in dem Sie mit der Unis über bestimmte Technologien austauschen, es kann doch nicht wahr sein , dass die wirklich gute Fachleute ins Rente geschickt werden ohne vorher das Wissen an das zukünftige Generation vermittelt wurde! Ich sage mal es kostet deutlich mehr ohne Mentor sich das Wissen anzueignen als mit jemand der schon alle Strickfälle von der Programmiersprache gesehen hat.

Cobol ist im Trend , Java weiterhin auch im Trend, aber es gilt bei mir nach wie vor Kunde ist ein König! 

Blog-Archiv

Blog readers favorites