- RSS Channel Showcase 5925751
- RSS Channel Showcase 4921809
- RSS Channel Showcase 7958397
- RSS Channel Showcase 7916295
Articles on this Page
- 09/21/13--22:25: _How can Agile help ...
- 10/09/13--07:54: _On the way to a blo...
- 10/22/13--08:42: _A MindMap for Java ...
- 12/18/13--04:05: _Does the View in da...
- 01/02/14--05:17: _Why is tomcat a Web...
- 02/23/14--00:47: _4 simple steps to m...
- 03/01/14--08:13: _TalkNotes - The sto...
- 03/24/14--06:49: _Integration Testing...
- 05/04/14--00:43: _EXIN Cloud Computin...
- 07/18/14--01:27: _Identifying the ski...
- 01/24/16--22:23: _Application Securit...
- 04/18/16--01:55: _Do you need microse...
- 08/01/16--03:32: _An approach to help...
- 11/03/18--09:45: _Practical communica...
- 09/21/13--22:25: How can Agile help you in clearing the technical debt?
- 10/09/13--07:54: On the way to a blogger - My Journey with this blog so far
- 10/22/13--08:42: A MindMap for Java Developer Interviews
- 12/18/13--04:05: Does the View in database reduce the query performance?
- 01/02/14--05:17: Why is tomcat a Webserver and not an Application Server
- 02/23/14--00:47: 4 simple steps to migrate legacy projects from Ant to Maven
- 03/01/14--08:13: TalkNotes - The story of SonarQube told to a DevOps Engineer
- 05/04/14--00:43: EXIN Cloud Computing Foundation Exam Review
- 07/18/14--01:27: Identifying the skills gap for a Software Developer
- 01/24/16--22:23: Application Security for Java Developers
- 04/18/16--01:55: Do you need microservices architecture?
- 08/01/16--03:32: An approach to help developers write meaningful tests
- 11/03/18--09:45: Practical communication strategies for software architects
Defining Technical DebtAs per Wikipedia, "Technical debt metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a code base". Technical debt is most understood when it is compared with Cost of Change of software. More Debt means the cost of introducing a change in your system is more.
Technical Debt in Agile ContextThe below principle from the list of agile principles was the best one I could find which refers to clearing technical debt "Continuous attention to technical excellence and good design enhances agility". In agile projects working software has a lot of emphasis but this in no way implies that the intrinsic value of software can be compromised. As we push for more and more features it is important that we take time to look back at the health of the application. So, make make sure that your agile projects do not become Fragile as it grows.
The second techniques that we have tried to minimize technical debt is to negotiate with the product owner and take him on board in the technical improvements that we wanted to do. You have to Use the opportunity of Change requests to clean up the functionality. We had a module in our application with lots of bugs. There was a major change request which was planned on that module. After much discussions we identified that it would be much easier to rebuild the module than fixing the issues. Once we rebuild the change request was 75% easier to implement compared to the old code.
Note:- There are many ways to define and minimize technical debt. I have discussed few ways that we have successfully tried. You can go through the above links to find more information and choose the best methods that suits you.
XMind gives a nice listing of the map. You can find the map here. Here is Image which you can download and use.
Finally here is a old fashioned tabbed content list which is easier to copy paste.
Interface - Abstract Class
IS-A vs HAS-A Relationships
Aggregation vs Composition
Method overloading vs Method Overloading
Compile time vs Runtime
Shallow copy vs Deep Copy
Map, List and Set
Equals - Hashcode
Legacy - Synchronized Classes
Stack vs Heap Memory
JRE, JVM, JDK
Checked Vs Unchecked Exceptions
Exception handling best practices
try, catch, finally, throw, throws
String - StringBuffer - String Builder
SAX Based & DOM Based
JAXB - Java API for XML Binding
Packaging the Applications
SOAP, WSDL Webservices basics
Contract first vs
RESTful and its advantages
This is a work in progress and I hope to refine it further. Let me know if you have any comments.
Any third party jars can be added to the maven repository as told here. If you are using very old versions of jar files some of them may not be available in maven repository.Here you can either try upgrading to newer versions or prepare local install as told before. Once you have added all the dependencies try building the application. Watch out for any major issues.
Maven is a build tool. This means your WAR should not change. So, in the last step we compare both versions and make sure they are the same. Make sure you are on top of all the differences. Also, compare the jar files generated by maven and your existing files, Sync them by
Most examples of connecting to database in spring is done using DriverManagerDataSource. If you don't read the documentation properly then you are going to miss a very important point.
1. Server (Container) managed connection pool (Using JNDI)
2. Application managed connection pool
Below user guides can help you configure this.
The below articles speaks about the general guidelines and best practices in configuring the connection pools.
3. How to decide the max number of connections
4. Monitoring the number of active connections in SQL Server 2008
Note:- All the text in italics are copied from the spring documentation of the DriverManagerDataSource.
The principles of Cloud Computing. This chapter deals with definitions, types of clouds (Public, Private and Hybrid) and cloud services (IAAS, PAAS, SAAS).
Most contents in the section are from the The NIST Definition of Cloud Computing paper. Other topics include The Evolution Toward Cloud Computing, Cloud Computing Architectures and Benefits and Limitations of Cloud Computing. The part about Virtualization and its role in the raise of Could computing was quite interesting for me.
Using the Cloud. This part is about accessing the cloud and mobility in the cloud.
This module covers the topics Overview of Accessing the Cloud, How Cloud Computing Can Support Business Processes and Service Providers Using the Cloud.
Security and Compliance. Is about the risks of cloud computing and the measures you can take
This module covers the paper Top Threats to Cloud Computing prepared by the Cloud Security Alliance under the Security Risks and Mitigating Measures title. Managing Identity and Privacy section deals with Triple-A authentication and various aspects of identity management.
Implementing and managing Cloud Computing. You learn about local cloud networks and how to support the use of cloud computing
This module includes the topics Building a Local Cloud Environment and Managing Cloud Services. There is a lot of focus on managing cloud services and related governance frameworks.
Evaluation of Cloud Computing. Examples of the subjects here are cost aspects, (dis)advantages and SLA’s.
This module speaks about the business case for cloud computing. For example cost implications to an organization evaluating the cloud services in terms of capex and opex. Forming the Service level requirements and agreements.
The text in italics are taken from the official exam page.
Written with StackEdit.
|B. Section||C||D. These things happens with You||E. Your Action Plans|
Understanding what to do
|What to do? (40%)||
1. You have missed some of the requirements.
2. You hear others say "This feature was not supposed to work like this"
3. Your completed work gets re-opened during QA or User Testing.
|-Improve your domain knowledge.
-Ask more questions to your PO so that you can impove your understanding of the requirements.
-Push for improved requirements documentation.
-Spend more time in testing your features.
-Listen to sprint demos to get the overview of all the new features added.
Knowledge of Frameworks,
Design patterns, practices and principles
|How to do it - Your skills to do it
(20 - 30 %)
1. You don't know where to start with when you have to implement a new feature
2. You don't know if a similar functionality already exists in the application or not
3. You don't completely understand the frameworks in the application and how they are used
|-Pair program with an experienced developer to learn how he approaches a problem.
-Learn more about the frameworks used in your app.
-Try creating sample applications using them.
-Identify the patterns and principles used in your app and try to use them.
|3||Problem solving, Analytical, Debugging skills||
How to do it - Your Ability to do it
(10 - 20 %)
1. You face difficulties when it comes to writing algorithms
2. You are weak in debugging and finding issues in the code
|-See if you can apply some known patterns to solve the problem.|
|4||Communicating with your code||How well you did it?
How easily somebody can understand how ?
1. Your code is not up to the standards or frequently ignores code quality.
2. You don't have enough code coverage
3. You can't write a quality documentation
|-Use tools like sonar to asses the quality of your code.
-Spend more time in refactoring and improving the code quality.
|5||Communicating about your work||
How well can you communicate about your work
1. Your don't follow the process in the team.
2. Your check-in comments are not useful.
3. Your team don't know what you are working on.
|-Understand and adhere to the team policies. If you feel that there is somethings wrong, communicate and get it clarified.
1. Authentication and AuthorizationWhen it comes to security the most fundamental concepts are Authentication and Authorization. Unless you have a strong reason you should be following a widely accepted framework for this purpose. We have Java EE Authentication and Spring Security to help us out in this context. I have worked with spring security in the past and it can be customized to suite your specific needs.
2. Security in the Web LayerIn our application stack the web layer is most vulnarable to attacks. We have may established standard practices and detection mechanisms to minimize these risks. OWASP Top 10 list is a must have check point for security checks. The Open Web Application Security Project (OWASP) mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.
3. API SecurityWith the rise of mobile applications and stronger browsers expressing functionalities using the API is more popular day by day. We need to follow the same security practices for the web layer. All the API requests should be authenticated and we should use the principle of least privilege. I found the presentation from Greg Patton in the AppSec EU15 titled The API Assessment Primer is a great start for API security validations. Two major points focused in his talk are,
Do not expose any operations that are not needed
Do not expose any data that is not required
Which is in line with the basic security principle of giving least privilege by default.
To authenticate the services, we can create simple token-based API authentication mechanism based OAuth2 standards. If the services expose any sensitive data, it is better to use https so that man-in-the-middle attacks can be avoided.
Other Useful Reference Materials
|Tests||Naming convention||Runs at||When to use||Exec Time|
|Unit Test||Ends with Test||Every build||Rule based implementations where the logic can be tested in isolation||Few Milliseconds|
|App Level Tests||Ends with TestApp||Every build / Nightly builds (Teams choice)||Tests the service layers in connection with others. Frees you from creation of mock objects. Application context is loaded in the tests.||Few Seconds|
|Integration Test||Ends with TestIntg||Runs on demand when a special profile is used in build.||All the above + Use when you need to connect to external points like DB, web services etc..||Depends on the integration points.|
|Manually Running Tests||Ends withTestIntgManual||Manually running tests, Used debugging a specific problem locally||All the above - Can't be automated.||Depends on the integration points.|
Here is a video recording of my session titled Practical communication strategies for software architects on Bangalore software architect meetup.
The session covers communication ideas for various stages and to different stakeholders in a project scenario.
Have a look at the video recording of the session