Category: Software Engineering

  • Agile Building 2

    Agile Building 2

    Next post in our series where we compare the similarities between civil and software engineering.

    A new house is under construction. After completing the outer walls, it’s the time to create the internal room arrangements. (keep in mind that minor changes in the internal room arrangments do not violate the official house license and are completely legal.)

    In photo 1 we can observe that the engineer started the construction of the internal walls and stopped until a specific point when the photo was taken. Observe the way that the bricks are left in a “pending” state, ready to accept extension with more bricks as highlited in the yellow boxes.

    At this point the owner (product owner :p) was asked by the engineer to observe the result until then and provide feedback (review). What will be the arrangement of the rooms? Where will be the bed and the cupboard placed? What will be the direction of the door openings?

    The owner can change her mind or thing carefully about all of the above decisions without affecting the progress so far.

    Answering all the above questions led to a result like the one in picture 2. The yellow lines indicate the finalized lengths of the walls that determined: 1. the exact openings of the two rooms. The width of the openings. The length of the walls inside the room, at the left and the right side of the door. This in turn will dictate the placement of the bed, the cupboard and maybe the office in the one room (right) and the arrangement of bath furniture in the other room (left).

    A change in the design of the walls now, will have far more negative impact in the building progress and will definitely create tension between the owner and the engineer. Nobody likes late change, especially if it involves demolition of already created walls and extra labor days!

    The experienced engineer applied a common way of work among engineers to do with everyday job. This way of work is also very familiar in our industry, as it reflects a well known agile principle: “fail fast”!

     

     

     

     

     

     

     

     

     

     

  • Agile Building 1 (well kind of..)

    Agile Building 1 (well kind of..)

    This is a first post on a series that I want to publish regarding the connections between the (ancient) science of civil engineering and software engineering.

    An industrial style renovation of a restaurant in Athens, removed the plaster from the walls and revealed the raw concrete contruction as depicted below. It the articulation point of a column pillar and a beam. Very critical for the stability of the building.

    That was at least the initial plan of the engineer, because the electrician that installed the structured wiring system, considered usefull to dig into the concrete in order to lower it and make a nest to cover the cable branching boxes. But this decision had critical effect on the stability of the structure

    Whose fault is this? Bad communication between teams? Negligence of the civil engineer? We will never know. The only sure fact is that this decision was not in favor the quality of the construction.

    We can easily ignore this fault as minor, but do not know the exact number of similar faults. And it is very difficult, nearly impossible to find out! So… fingers crossed and pray for mild earthquakes!

    How many similar analogies can we draw with the software engineering field?

    #softwareengineering
    #civilengineering

  • How to configure maven build for a single project for multiple environments

    This post shows how to configure maven build for a single project that needs to be deployed to multiple  environments. In other words, when we need a common code base that can be built towards STAGING or DEVELOPMENT environment or for WILDFLY / WEBLOGIC / TOMCAT application servers.

    The source code of the complete example is here

    The structure of the multi-module maven example project is the following:

    For this example, we want to build different releases of our modules depending on the deployment target. This is because Wildfly and Weblogic environments demand slightly different persistence.xml files. Therefore, the multiple-env-jpa module which contains the JPA Entities and the persistence.xml file, should contain the proper persistence.xml flavor, depending on the target server. For this reason, jpa module contains 2 different files with 2 configurations as shown in the figure below.

    During build, we configure maven to copy -> rename a select file, either weblogic-persistence.xml or wildfly-persistence.xml as the final: persistence.xml

    <parent>
        <groupId>com.intrasoft</groupId>
        <artifactId>multiple-env-demo-parent</artifactId>
        <version>${revision}</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    
    <artifactId>multiple-env-jpa</artifactId>
    
    <build>
        <plugins>
            <plugin>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <classifier>${target.server}</classifier>
                </configuration>
            </plugin>
            <plugin>
                <groupId>com.coderplus.maven.plugins</groupId>
                <artifactId>copy-rename-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
    
    <profiles>
        <profile>
            <id>wildfly</id>
            <properties>
                <target.server>${wildfly.suffix}</target.server>
            </properties>
    
            <build>
                <pluginManagement>
                    <plugins>
                        <plugin>
                            <groupId>com.coderplus.maven.plugins</groupId>
                            <artifactId>copy-rename-maven-plugin</artifactId>
                            <version>1.0.1</version>
                            <executions>
                                <execution>
                                    <id>rename-file</id>
                                    <phase>validate</phase>
                                    <goals>
                                        <goal>copy</goal>
                                    </goals>
                                    <configuration>
                                        <overWrite>true</overWrite>
                                        <sourceFile>${basedir}/src/main/resources/META-INF/wildfly-persistence.xml</sourceFile>
                                        <destinationFile>${basedir}/src/main/resources/META-INF/persistence.xml</destinationFile>
                                    </configuration>
                                </execution>
                            </executions>
                        </plugin>
                    </plugins>
                </pluginManagement>
            </build>
        </profile>
        <profile>
            <id>weblogic</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <target.server>${weblogic.suffix}</target.server>
            </properties>
            <build>
                <pluginManagement>
                    <plugins>
                        <plugin>
                            <groupId>com.coderplus.maven.plugins</groupId>
                            <artifactId>copy-rename-maven-plugin</artifactId>
                            <version>1.0.1</version>
                            <executions>
                                <execution>
                                    <id>rename-file</id>
                                    <phase>validate</phase>
                                    <goals>
                                        <goal>copy</goal>
                                    </goals>
                                    <configuration>
                                        <overWrite>true</overWrite>
                                        <sourceFile>${basedir}/src/main/resources/META-INF/weblogic-persistence.xml</sourceFile>
                                        <destinationFile>${basedir}/src/main/resources/META-INF/persistence.xml</destinationFile>
                                    </configuration>
                                </execution>
                            </executions>
                        </plugin>
                    </plugins>
                </pluginManagement>
            </build>
        </profile>
    </profiles>

    The 2 different profiles are defined in the parent pom, one for the weblogic build and one for the wildfly build, in each profile, we initialize the target.server variable accordingly:

    <profiles>
        <profile>
            <id>wildfly</id>
            <properties>
                <target.server>${wildfly.suffix}</target.server>
            </properties>
        </profile>
    
        <profile>
            <id>weblogic</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <target.server>${weblogic.suffix}</target.server>
            </properties>
        </profile>
    
    </profiles>
    
    <properties>
    
        <revision>1.3</revision>
        <weblogic.suffix>WLOGIC</weblogic.suffix>
        <wildfly.suffix>WFLY</wildfly.suffix>
    
    </properties>

    The only thing we should do, is to fire a maven install:

    mvn clean install

    But the problem is that we want to differentiate the final jar, in order to distingush somehow if it was made for wildfly or for weblogic environment. We cannot change the name of the jar dynamically (of course!) and we also cannot use different versions.

    Thankfully maven gives us the solution with the classifiers. We can define and configure the maven jar plugin in the jpa module:

    <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
            <classifier>${target.server}</classifier>
        </configuration>
    </plugin>

    This will automatically append during package phase the classifier name at the end of the jar file:

     

     

     

     

     

     

     

    In order to use a specific “flavor” (either the weblogic, or the wildfly) of the jpa packages, the clients of the jpa module must also define the necessary classifier in the dependency declaration.

    This is for example, the pom.xml of the multiple-env-service module, which needs the jpa module:

    <dependencies>
    
        <dependency>
            <groupId>com.intrasoft</groupId>
            <artifactId>multiple-env-jpa</artifactId>
            <version>${project.version}</version>
            <classifier>${target.server}</classifier>
        </dependency>
    
        ...
    
    </dependencies>

    So to make the service module fetch the wildfly flavor of the multiple-env-jpa library we should build it like this:

    mvn clean install -P wildfly

    That’s all!

     

     

    The source code of the complete example is here

     

  • Cloud computing

    Cloud computing

    Cloud computing has nowadays become the platform of the new, global digital transformation not only for our countries, governments and companies but for each one of us. Our phone contacts, photos and messages are stored in cloud datacenters. Music and videos are being delivered through high capacity cloud streaming services. Best route finding on maps with live traffic information is made possible with Artificial Intelligence cloud services. Tax income declaration is being applied through the cloud. Even, registration to kindergarten schools in Greece is being performed for the first time by using online family status verification through the public registry, again by leveraging cloud technologies! Cloud computing is ubiquitous either we use it deliberately or not.

    But what is the actual meaning of this “cloudy” term? Is data being transferred to the sky clouds for some purpose? Probably not!

    Cloud Computing is the on-demand delivery of computing services such as servers, databases, networking structures and software over the internet. This is implemented by dedicated datacenters and server farms whose services are available to many different customers/users, offering faster innovation, flexible resources, and economies of scale. Cloud computing services are based on a “pay-as-you-go” model which means that clients are only charged for the services they use.

    Cloud computing centers are divided in three major categories.

    Public clouds are operated by third-party companies such as Microsoft (Azure) or Amazon (AWS) which are responsible for the stability, maintenance and expansion of the underlying infrastructure, and provide their service over a public network, the internet.

    Private cloud is structurally identical to the public cloud, but it is being owned and used by a single organization while the provided services are restricted to a private network.

    Hybrid cloud combines private and public clouds connected with technology that enables data and applications to be interchanged between them. This interconnection offers higher flexibility and more deployment options.

    Types of cloud Computing services

    Cloud Computing can be provided through different models according to the abstraction level and the complexity of the underlying services. The three standard models according to NIST are:

    • Infrastructure as a service (IaaS): The basic category of cloud computing. Users rent servers, networking hardware, storage devices and operating systems and configure them to provide business value. Users are responsible for system configuration, operating system updates and vulnerability eliminations.
    • Platform as a service (PaaS): Ideal for developers who want to quickly deploy a web application without having to setup servers, operating systems and networking, as they are already configured. In other words, PaaS is an environment created on-demand for developing, delivering and administering web applications.
    • Software as a service (SaaS): Here the whole application lifecycle as well as the underlying infrastructure, the configuration and administration tasks are performed by the cloud provider. Users interact with the application through a web browser or mobile device.

    The Pizza Analogy

    All these new terms can be confusing, even experienced software engineers found the concept delineation difficult. For this purpose, the famous Pizza Analogy has been created. On the first column there is the equivalent to the non-cloud traditional application deployment process. All tasks are being handled by the user. While on the other hand, the last column represents the equivalent to SaaS approach where every single task is being “outsourced” to the Cloud Service Provider leaving to the user only the pizza delight!

    Latest advances

    Cloud Native

    Inevitably, the transition to cloud computing was not spontaneous. Cloud services were initially used mainly as infrastructure (IaaS), that is online, on-demand Virtual Machines which hosted operating systems configured by the end-user. As it was growing up, it became obvious that effective leverage of cloud advantages will be made possible only by applications tailor-made for cloud environment, or as they became known, Cloud Native.  Applications of this type are especially designed and developed for cloud deployment, are based on microservices architectures, leverage scaling features, and benefit from continuous delivery to achieve reliability and rapid response to business requirement changes.

    Multicloud

    Multicloud is the employment of cloud services from different service providers in a single heterogenous architecture to meet different technical or business requirements. Usually it is implemented by distributing cloud native applications to several cloud hosting environments. The main reasons that favor multicloud deployments include reducing reliance on a single vendor, increasing flexibility and adhering to local data protection policies.

    Benefits and Pitfalls

    The advantages of Cloud Computing can be easily identified. A third-party company that specializes on server hosting and deployment can achieve economies of scale, provide safer infrastructure that is already updated with latest vulnerability updates, guarantee a reliable platform with zero downtime and the most important, offer global-scale availability. This enables a small startup somewhere in the world to deploy a new innovative web application with global availability by paying only for the computing power, traffic and services it uses. Only consider the costs of these requirements for a self-hosted infrastructure alternative!

    However, as every powerful weapon, Cloud Computing requires careful configuration from highly experienced users. The “pay-as-you-go” model can lead to unexpected operating expenses if administrators are not familiar with cloud-pricing models. Furthermore, the offered services are limited by the cloud provider decisions which results to limited platform customization options.

    Data security is another critical area that poses serious concerns about Cloud computing, especially public ones. Cloud providers have access to user data that can be accidentally or deliberately modified or leaked to external parties. Data ownership is still a vague field on cloud computing Terms of Service Agreements that poses questions about the accountability on possible data misusage events. Due to these concerns, cloud computing is still not the first option for government, military and security critical applications.

    Top Cloud Providers according to revenue

    1. Amazon Web Services
    2. Microsoft Azure
    3. Google Cloud
    4. Alibaba Cloud
    5. IBM Cloud
    6. VMWare Cloud
    7. Hewlett Packard Enterprise
    8. Cisco Systems
    9. Salesforce
    10. Oracle Cloud

     

    Bibliography

    Barron, Albert. “Pizza as a Service.” Accessed May 31, 2020. https://www.linkedin.com/pulse/20140730172610-9679881-pizza-as-a-service/.

    “Cloud Computing.” In Wikipedia, May 30, 2020. https://en.wikipedia.org/w/index.php?title=Cloud_computing&oldid=959841571.

    “Cloud Computing @ Microsoft Azure.” Accessed May 31, 2020. https://azure.microsoft.com/en-us/overview/what-is-cloud-computing/.

    “Cloud-Native Applications | Microsoft Azure.” Accessed May 31, 2020. https://azure.microsoft.com/en-us/overview/cloudnative/.

    Drake, Nate, Brian Turner December 20, and 2019. “Best Cloud Computing Services of 2020: For Digital Transformation.” TechRadar. Accessed May 31, 2020. https://www.techradar.com/best/best-cloud-computing-services.

    McLellan, Charles. “Multicloud: Everything You Need to Know about the Biggest Trend in Cloud Computing.” ZDNet. Accessed May 31, 2020. https://www.zdnet.com/article/multicloud-everything-you-need-to-know-about-the-biggest-trend-in-cloud-computing/.

    Mell, Peter, and Tim Grance. “The NIST Definition of Cloud Computing.” National Institute of Standards and Technology, September 28, 2011. https://doi.org/10.6028/NIST.SP.800-145.

    “Multicloud.” In Wikipedia, February 15, 2020. https://en.wikipedia.org/w/index.php?title=Multicloud&oldid=940901545.

    Cisco. “What Is Cloud Computing? – Cloud Computing Definition.” Accessed May 31, 2020. https://www.cisco.com/c/en/us/solutions/cloud/what-is-cloud-computing.html.


     

     

    This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 871177
  • Async Rest with Completable Future, Async CDI Events and Java EE 8

    Rest

    https://gist.github.com/teohaik/aa0354e3b9815ee9f700d7c0b1f2a668

    Service

    https://gist.github.com/teohaik/cdfd6f30a9d156f39b8ef9b26ae545df

  • How to untrack files in Git

    How to untrack files in Git

    We all know how to add a file under Git tracking.

    But what can we do to untrack a file or directory?

    To untrack a file:

    git rm --cached filename

    To untrack a directory (recursively)

    git rm -r --cached dir_name

    If you develop with Intelij tools you can use the nice and helpful .ignore plugin

  • Useful Git image

    Useful Git image

    Everybody gets confused with this, so I added a useful memo image


     

     

     

     

     

     

     

     

     

     

    Credits

     

  • Bug in Magnetice Resonance Imaging (MRI) Software invalidates results of last 15 years!

    Bug in Magnetice Resonance Imaging (MRI) Software invalidates results of last 15 years!

    Scientists led by Anders Eklund from Linköping University in Sweden recently announced a bug in the software that transalates results from MRI machines.

    The bug is related to a specific type of exam, called ‘functional MRI’. In this exam, the patient is given a specific task to carry out while at the same time his brain is monitored by an MRI machine. MRI captures differences in blood activity and the underlying software translates the data into simple results that state whether or not there is activity in a specific brain section.

    But the bug that was found threatens the validity of results from the last 15 years!

    More info on the article from Science Alert

  • Frequently Forgotten Fundamental Facts about Software Engineering

    A few day ago, I ran into a very interesting article by Robert L. Glass, published on 2001 at the IEEE Software

    Among other very interesting facts, it highlights maintenance costs:

    Maintenance

    M1. Quality and maintenance have an interesting relationship.

    M2. Maintenance typically consumes about 40 to 80 percent (60 percent average) of software costs. Therefore, it is probably the most important life cycle phase.

    M3. Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. So, software maintenance is largely about adding new capability to old software, not about fixing it.

    M4. The previous two facts constitute what you could call the “60/60” rule of software.

    M5. Most software development tasks and software maintenance tasks are the same—except for the additional maintenance task of “understanding the existing product.” This task is the dominant maintenance activity, consuming roughly 30 percent of maintenance time. So, you could claim that maintenance is more difficult than development.

    FULL TEXT