jyops.blogspot.com Open in urlscan Pro
2607:f8b0:4006:81f::2001  Public Scan

Form analysis
0 forms found in the DOM

Text Content

THE OBJECT ORIENTED LIFE







BUILDING EVOLUTIONARY ARCHITECTURES - BOOK REVIEW


 0 Google +0

 6











In this blog, I want to speak about the book Building Evolutionary Architectures
by Neal Ford, Rebecca Parsons, and Patrick Kua. I have attended Neal's
conference talk on this topic and heard from many other speakers about the
fitness functions. That’s the reason I wanted to read and understand the
concepts mentioned in the book.



As the title implies, the book talks about building evolutionary architecture.
The question that the book trying to solve is, how do we make sure, our software
architecture stays intact with the changing requirements? How do we build the
system which can adapt to future needs or how do we know the decision that we
are taking is not impacting the architecture of the system?

The book speaks about fitness functions, to solve this concern. An architectural
fitness function provides an objective integrity assessment of some
architectural characteristics. So, in a system there may be many characteristics
that we want to measure, so you would write separate fitness functions for each
of them. In the book, a fitness function is not defined in a concrete way but
rather in an abstract form of graphs, tests or any other methods by which we
know that our system is doing good with the change. This means you would still
need to use your intellect not only to write the fitness function but also to
make sense of them.

For me, the best thing about the book is, it provides software architects with a
rich vocabulary to communicate their intentions behind their choices to a
variety of audiences, including business stakeholders, teams, and engineering
leadership. The book also gives you a survey of various architectural
approaches. It also talks about some of the practical ideas on how do we
implement evolutionary architectures I particularly like the focus on the
organizational factors and how does it apply to the software architectures.

In conclusion, I would recommend this book to any software architect. Use it as
your communication guide, use it to improve your vocabulary, use it to get a
sense of what is happening across the industry, so that you could choose what
best for your situation.

Posted by ManuPK at Saturday, March 21, 2020 1 comments




4 WAYS TO CONTRIBUTE TO THE COMMUNITY FOR A SOFTWARE DEVELOPER


 0 Google +0

 6


If you are a software professional and looking for something new to start here
are the 4 things to try for!




1. ATTEND A COMMUNITY EVENT OR USER GROUP GETTOGETHER OR LOCAL MEETUP





2. ANSWER QUESTIONS AT THE STACKOVERFLOW OR CONTRIBUTE TO SUPPORT FORUMS




3. SHARE YOUR EXPERIENCE VIA BLOG OR TWITTER OR OTHER FORUMS WITH THE COMMUNITY.





4. CONTRIBUTE TO OPENSOURCE 





Posted by ManuPK at Sunday, December 22, 2019 1 comments




WHEN TO STAY WITH MODULAR MONOLITHS OVER MICROSERVICES


 0 Google +0

 6


We have seen the developments in the microservices architecture maturing, where
by more and more people are trying to evaluate the benefits before jumping on to
the unknown trajectory.

In the talk titled When to stay with modular monoliths over microservices at
Oracle Code, Bangalore, I tried to discuss these points. You can view the slides
below.



When to stay with modular monoliths over microservices from Manu Pk

According to me, Over simplified version of decision tree come down to two
criteria's, Business Context & Relative Scaling. I tried to explore the same in
my presentation. As Martin Fowler puts it, you shouldn't start a new project
with microservices, even if you're sure your application will be big enough to
make it worthwhile.






Here is a link to the YouTube Recording of the session. Let me know what you
think about these topics.




Posted by ManuPK at Friday, March 15, 2019 0 comments




PRACTICAL COMMUNICATION STRATEGIES FOR SOFTWARE ARCHITECTS


 0 Google +0

 6



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.

 

Practical communication strategies for software architects from Manu Pk


Have a look at the video recording of the session



Posted by ManuPK at Saturday, November 03, 2018 0 comments




AN APPROACH TO HELP DEVELOPERS WRITE MEANINGFUL TESTS


 0 Google +0

 6


Over the last few years we have been adding unit tests to our existing product
to improve its internal quality. During this period we always had the challenge
of choosing unit-vs-Integration tests. I would like to mention some of the
approaches we have applied to improve the quality of existing system.


At its core, unit testing is about testing a single component at a time by
isolating its dependencies. The classical Unit tests have these properties
"Fast, Independent, Repeatable, Self-Validating,Timely". Typically in java a
method is considered as a unit. So traditional  (and most common) approach is to
test the single method of a class separated from all its dependencies.


Interestingly there is no hard-core definition of "what makes a unit". Many
times a combination of methods which spread across multiple classes can form a
single behavior. So in this context the behavior should be considered as a unit.
I have seen people breaking these units and writing multiple tests for the sake
of testing a single method. If the intermediate results are not significant this
will only increase the complexity of the system. The best way to test a system
is to test with its dependencies where ever we can accommodate them. Hence we
should try to use the actual implementation and not mocks. Uncle bob puts this
point very well, "Mock across architecturally significant boundaries, but not
within those boundaries." in his article.


If the software is build with TDD approach it might not be a challenge to
isolate dependencies or adding a test for your next feature. But not all
software's built like these. Unfortunately we have systems where there are only
few or none of the test are written. When working with these systems we
can  make use of the above principle and use tests at different levels. Terry
Yin provides an excellent graphics (which is show below) in his presentation
titled Misconceptions of unit testing. This shows how different tests can add
values and what are its drawbacks.







Many of our projects uses Java and Spring framework. We have used
springs @RunWith and SpringJUnit4ClassRunner to create AppLevel Tests which
gives you the objects with all its dependencies initiated. You could selectively
mock certain dependencies if you would like to isolate them. This sets a nice
platform to write unit tests with multiple collaborating objects. we call them
App level tests. These are still fast running test with no
external dependencies. A different term was chosen to differentiate itself from
the classical unit test. We also had Integration test which would connect with
external systems. So, the overall picture of developer tests can be summarized
as below,  








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.




This approach gives the developers choose the right level of abstractions to
test and helps in optimizing their time. Nowadays my default choice is App Level
tests and I go to unit tests if I have a complicated logic to implement.



Further reading:


http://martinfowler.com/bliki/UnitTest.html
http://blog.manupk.com/2011/11/when-to-replace-unit-tests-with.html
http://blog.8thlight.com/uncle-bob/2013/03/05/TheStartUpTrap.html
http://codeofrob.com/entries/uncle-bobs-viewpoint-considered-harmful.html
http://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
http://bryanpendleton.blogspot.in/2015/04/on-testing-strategies-and-end-to-end.html
https://www.symphonious.net/2015/04/30/making-end-to-end-tests-work/
https://www.thoughtworks.com/insights/blog/mockists-are-dead-long-live-classicists





Posted by ManuPK at Monday, August 01, 2016 0 comments




DO YOU NEED MICROSERVICES ARCHITECTURE?


 0 Google +0

 6








Over the last few years there has been lot of attention on microservices. After
the initial "hype" we saw that what problems it solves and what it can not. I
have tried to cover what are microservices and where it can be useful and where
it is not. I want to share the guidelines which can be used to choose between a
monolith and microservices.


I feel that one must answer the below questions before they choose a
microservices architecture and it will be beneficial to you if the answer to
these questions are "YES".


1. Does your services represents different business cases/domains..?
2. Does the services needs to be deployed and managed independently..?
3. Does different parts of the application has different scaling/Technology
needs..?


A modular monolith can be transformed to a set of microservices in case the need
arises. So, we should start with monolith when we are not sure about the future.






Do you need microservices architecture? from Manu Pk

I have spoken couple of times about the microdervices. In April 2016, I spoke at
the Bangalore Software Architects Meetup on the topic "Do you need microservices
architecture?". Later in 2017 April there was a brief introductory talk titled,
Introduction to Microservices at the Microservices and Serverless event. I hope
this post helps to complement the slides.





Introduction to Microservices from Manu Pk

Posted by ManuPK at Monday, April 18, 2016 2 comments




APPLICATION SECURITY FOR JAVA DEVELOPERS


 0 Google +0

 6


Security is a top priority item on everyone's checklist nowadays. In this post,
I will introduce you to useful reference material that can help you get started
with securing applications. I want to focus more on web applications built with
Java related technologies.





1. AUTHENTICATION AND AUTHORIZATION

When 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 LAYER

In 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 SECURITY

With 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.



4. VALIDATING THE USER INPUT

Be aware that any JavaScript input validation performed on the client can be
bypassed by an attacker that disables JavaScript or uses a Web Proxy. Ensure
that any input validation performed on the client is also performed on the
server. Go through the OWASP and WASC checklist to identify the potential
validations you need to do in your application.

Other Useful Reference Materials

1. A Security Checklist for Web Application Design
2. Java EE Security

Posted by ManuPK at Sunday, January 24, 2016 2 comments


Older Posts Home

Subscribe to: Posts (Atom)



SUBSCRIBE








STACK EXCHANGE PROFILE




My posts @ JCG


My posts @ DZone



TOPICS

bestpractice example java speaking career architecture books hibernate technical
debt



POPULAR POSTS

 * Top 10 Java Books you don't want to miss.
 * Using Jasper Reports to create reports in Java
 * Useful Eclipse Plugins that didn't make it to the Top 10 list
 * Java Memory Profiling Simplified
 * All about Hibernate Second Level Cache




FOLLOWERS




BLOG ARCHIVE

 * ▼  2020 (1)
   * ▼  March (1)
     * Building Evolutionary Architectures - Book review

 * ►  2019 (2)
   * ►  December (1)
   * ►  March (1)

 * ►  2018 (1)
   * ►  November (1)

 * ►  2016 (3)
   * ►  August (1)
   * ►  April (1)
   * ►  January (1)

 * ►  2014 (6)
   * ►  July (1)
   * ►  May (1)
   * ►  March (2)
   * ►  February (1)
   * ►  January (1)

 * ►  2013 (10)
   * ►  December (1)
   * ►  October (2)
   * ►  September (1)
   * ►  May (1)
   * ►  April (2)
   * ►  March (1)
   * ►  February (1)
   * ►  January (1)

 * ►  2012 (7)
   * ►  November (1)
   * ►  October (1)
   * ►  September (1)
   * ►  August (1)
   * ►  June (1)
   * ►  March (1)
   * ►  January (1)

 * ►  2011 (7)
   * ►  December (1)
   * ►  November (2)
   * ►  October (1)
   * ►  September (1)
   * ►  March (2)






This work is licensed under a Creative Commons Attribution 3.0 Unported License.

Watermark theme. Powered by Blogger.





ShareThis Copy and Paste