Awareness of Product Development

Software development can be understood simply as a program to receive inputs (i.e customer needs) and then produce outputs (i.e working software). It is worth it to know how many steps are in that program. When something gets stuck in a step, everyone is aware of that.

The first painting of my son

The General Process Big Picture

There are two main factors in this picture including the people with roles and their interactions. All people involved in developing the product know their responsibilities clearly and how to make things done right. Therefore, a good collaboration can be reached.

Product Roadmap Contribution

It would be great for developers to know what the next features to work on are as well as when those features will be delivered. Therefore, the product roadmap is very important.

The items in the roadmap should be contributed by ALL people involved in the product.

Because software engineers directly develop, test, delivery, and monitor the software, they should also contribute ideas to the roadmap.

How to contribute

- For small features, just create a User Story in the Product Backlog and share it with Product Owner (PO)

- For big features (knowns as Epic), create a document to describe it and discuss it with the PO.

Technical Consulting

The sales team, Product Manager, and PO work closely with customers. However, they are almost non-technical people. Therefore, technical consulting from Developers is needed.

Normally, the process of technical consulting consists of the following steps:

- Product Manager/Product Owner creates a document to describe the features' idea

- Developers describe the proposals including architectures and rough estimation. It is important that Developers are the ones who give the estimation directly. The Technical Architect plays the role of facilitating the team to have good proposals. Depending on the feature’s complexity, the research/spy user story should be created first.

For simple issues, technical consulting also can be simply conducted by direct communication without the need of creating a document.

Product Operation

Even though Developers do not operate and maintain the applications in the production environment, they should know how it is operated too. It will impact how the features are implemented as well as avoid some issues when running in production by implementing a good mechanism. Therefore, it requires some transparent information for them.

- A document describes the deployment views, infrastructure, practices, version, etc (i.e Confluence pages)

- Communication channels (i.e weekly catch-up)

Comments

Gzip upload on browsers

Today, I faced a problem that I could not upload my archive file with gzip format on Firefox, even it worked on Chrome. I was using macOS. My application had a setting to whitelist accepted files. I’ve already added "application/gzip" to that list. "It’s strange!", I thought. I finally figured out that my uploaded file's type actually was "application/x-gzip" on Firefox. I also asked my colleagues to check their uploaded files on Window and Ubuntu. Hmm… they were totally different! It was "application/x-compressed" on Window, and was "application/x-compressed-tar" on Ubuntu. In fact, gzip is already standardized by IANA. There is a note in RFC-6713 as below: "Some applications have informally used media types such as application/gzip-compressed, application/gzipped, application/x-gunzip, application/x-gzip, application/x-gzip-compressed, and gzip/document to describe data compressed with gzip. The media types defin...

Automating deployment and managing apps on OpenShift

Previously, we maintained OpenShift templates for deploying apps in development environments as well as delivering these templates to our customers for their on-prem deployment. Customers who refer to our templates (as well as documentation) have their own configuration management tools to automate the deployment such as ArgoCD and FluxCD. My son's buildings Our developers usually modify templates (YAML) directly on OpenShift for testing and then adjust the corresponding templates stored in the Git repository in Bitbucket. This sometimes causes an issue that delivered templates are incorrect because: - Developers forget to update the templates in Git repositories. - Developers don’t test the templates Therefore, our goal was to integrate a tool into our CI/CD that can automate and manage the configuration of OpenShift apps. The delivered templates should be the ones that are able to run on our OpenShift with the following purposes: - Automate deployment from templated in Git repos...

Junit - Test fails on French or German string assertion

In my previous post about building a regex to check a text without special characters but allow German and French . I met a problem that the unit test works fine on my machine using Eclipse, but it was fail when running on Jenkins' build job. Here is my test: @Test public void shouldAllowFrenchAndGermanCharacters(){ String source = "ÄäÖöÜüß áÁàÀâÂéÉèÈêÊîÎçÇ"; assertFalse(SpecialCharactersUtils.isExistSpecialCharater(source)); } Production code: public static boolean isExistNotAllowedCharacters(String source){ Pattern regex = Pattern.compile("^[a-zA-Z_0-9_ÄäÖöÜüß áÁàÀâÂéÉèÈêÊîÎçÇ]*$"); Matcher matcher = regex.matcher(source); return !matcher.matches(); } The result likes the following: Failed tests: SpecialCharactersUtilsTest.shouldAllowFrenchAndGermanCharacters:32 null A guy from stackoverflow.com says: "This is probably due to the default encoding used for your Java source files. The ö in the string literal in the J...

BIRT - Fix the size of an image

I use a dynamic image as a logo my report in pdf. At the beginning, I use table to align the logo in left or right. I meet a problem with some images with a large width or height. My customer requires that the logo should be displayed in original size. These following steps solves my problem: 1. Use Grid instead of Table 2. Set Grid "Height" is 100% and "Width" is blank 3. Set "Fit to container" for images are "true". Download the the template here .

My must-have apps for daily work

There is no doubt that cool apps can help us be more productive and enjoyable at work. For the time being, I really love the following apps which are used by me almost every day. 1. A personal Kanban In fact, a personal kanban is the most useful app for me. Why does it matter? It is not just a to-do list, but it keeps me motivated every day because it helps me be able to know what my "big picture" is. I usually set up my plans together with a path to reach them. KanbanFlow is my preferred tool. KanbanFlow 2. A terminal Needless to say, a terminal is a must-have app for every developer, especially the ones use macOS/Linux. Due to its importance, I love to decorate and enhance it to be super exciting with various tools such as iTerm , oh-my- zsh , and thefuck . ;) iTerm + oh-my-zsh 3. A documentation "ecosystem" As a developer, I can not remember all things that I have experimented a day. Moreover, a document is really useful for sharing an...

vhandit

Search This Blog