Skip to main content

Posts

From Basic To The Big Picture

This blog objective is to help a transition junior developer to be familiar with the big picture of software development environment. It is important for each team member in a team to realize their responsibility and work with each other. This blog content is based on IEEE Computer engineering society book called SWEBOK V3. Besides on the value of working in a team, it also will expose us to the standardization that has been drawn by IEEE/IEC/ISO. This will greatly improve the output product of the developed software.  Along the way while going through this blog, the journey of upgrading our knowledge will lead us to all the legal activities that involve in producing a software product as an output. We will discuss on how to patent our product and many more. It is worthwhile to understand what is our responsibility as a team member that will contribute to these legal issues.  At the end of the blog, we will encounter some of important knowledge that is out of the scope of a junio
Post a Comment
Read more
Recent posts

Looking At An Architecture Perspective In Software Engineering

It is very important to look things at a different way when we architect a system or module in the context of software engineering. Especially when we used to do things the 'developer' way. As a software architect, technology stack is like a plugin/tools to accomplish the desired output. This blog post will be discussing on how to visualize the idea on how to architect a system. Architect need to set in their mind that technology stack is not important, its the least of concern to a successful architect a shipped product. So what is a technology stack ?, We all aware for a software system/application to be considered shipped able, we require some sort like a persistent storage to store data. To tackle this, data storage technology is a stack, there are many technology that address this concern, we have database/blob/files even memory data store. Some of example products build by well known software houses that addressing this type of stack are Redis, MySQL, MSSQL, AzureCosmo
Post a Comment
Read more

Elements For Crafting Your Solution Privacy Policies

Introduction When we discuss policy creation elements in this context, we are talking about starting with business requirements (a task or series of tasks needed to serve a goal) and functionality goals. Once defined for goals and basic functions, we add requirements driven by applicable law. We then fit and bend our requirements to view the policies we must create through a lens of functionality (i.e., each action taken or demanded may be viewed as a requirement specification that must be included in a system). That system may be an enterprise, a subunit, end-to-end processing cycle, application, an element of functionality, a person-managed governance activity, among others. There is no exclusive list of what constitutes a system. This is not a discussion chief privacy officers (CPOs; or whomever is leading the privacy function) will have with every privacy engineer; however, every CPO must consider the output of his or her labor in terms of the concrete and measurable requirem
Post a Comment
Read more

Microservices - Anemic Models And Microservices Considerations

Anemic Model is considered an anti-pattern in Domain Driven Design. Based on Martin Fowler , Anemic model is a situation where we are declaring unnecessary model throughout our system. These model consists of classes that mostly having getter and setter. Anemic model does become a plague when we have n-tier application. Where each tier declared or created a specific classes to perform their task in their tier boundaries. Sometimes we are force to create a specific data model at a specific tier, but having unnecessary data model is what lead to Anemic Models symptom. In this article, we will discuss on how to design our system to reduce the risk of having Anemic Models. Properly Decide Your Micro services Domain/Functions We need to be able to get the big picture on how to design our micro services. It is not necessary to implement an atomic services for each table in a database for example. Having these pattern in our system will introduce a lot of soap/rest call to other servic
Post a Comment
Read more