Posted by: lrrp | November 20, 2018

What does not Kill you …..

Advertisements

Over the years, I’ve found myself in several less than ideal roles. For some odd reason, I thought that I was alone in this plight. But, have since realized that this assessment could not have been further from the truth. In fact, it is not uncommon to find ourselves in a role or an organization or both — not adequately aligned with our career goals. Indeed, no role is perfect. However, what if it becomes crystal clear that the fit just doesn’t seem to be there? We can’t simply pick up and leave — and in most cases no one would advise this. So, the looming question then becomes: What should you do while you wait for your next (and hopefully improved) opportunity?

Consider Jamie, an experienced professional who has re-entered an industry after a few years on the sidelines. The organization she recently joined is not fully aligned with the experience amassed in her core sector and she is feels incredibly challenged to keep up with the daunting learning curve. She realized that this first step back into full-time work wasn’t going to be perfect a fit. However, the on-going daily stress is challenging her resolve to stick things out for the longer haul. She knows this step is crucial, but feels she is quickly fading.

Of course, a poor fit isn’t reserved for seasoned professionals.

Jessica, a recent university graduate, entered the world of work with high expectations concerning what she might accomplish in her first year on the job. Active in clubs and organizations related to both her training and intended path she enjoyed a high level of both autonomy and respect. However, in her new world of work — she is faced with the challenge of proving herself once again. Her manager clearly isn’t open to new ideas from a less established employee and she is struggling to gain meeting invites. Frustrated and dejected, she toys with the idea of moving on to greener pastures.

Both situations are common — and potentially devastating. Having a heart-to-heart with yourself is often number one on the agenda. On some level, you must embrace the fact that this happens to many contributors and does eventually resolve.

Jill Katz Founder & CHRO at Assemble HR Consulting, shares this advice: “You would be surprised how often people feel stuck in their own role”. Jill who has led HR for several brands, including Macy’s and Calvin Klein continues, ” As we move into a world where personal and professional goals are blending — it is more important to get in touch with what we want — how to get it and how to manage the interim. One critical strategy is to be highly candid with a direct supervisor during the interview process and every week thereafter, to ensure the communication is fluid and open. More than not, these frustrations correlate with this process not occurring.”

In most cases, a combination of strategies can help us move forward effectively.

Here are a few to consider:

  • Get real. Expectations can be a real bear to deal with, especially when you’ve over-extended an idealized vision of the near future. If you’ve realized that you miscalculated a role’s potential or there were promises made that couldn’t possibly be met, you may find that a “come to reality” discussion with yourself may be in order. Clarify what you can — and cannot — accomplish career-wise in this role and emphasize the positives. Look for “smalls wins” that will feed your workplace soul.
  • Chill & give it time. Being impetuous is not a great virtue within the broader context of a career plan. If you are new to a role or organization, for example, give things at least 3-4 months to establish. This allows time to gain an understanding about the ways things work and for your manager and colleagues to learn your strengths. A career is not like microwaveable popcorn — things take time. If you’ve been with an organization for a time, you know how things can change and things can resolve for the better.
  • Look for an inspiring project. Organization work on many fronts. Seek a project with an inspiring mission, that might help build your connection to the organization and those within it. Staying 100% engrossed in work you do not connect with, is a miserable experience.
  • Glean what you can. If you can’t move into the right role, make a commitment to learn something valuable. You could seek inspiring individuals that might contribute to your development. For example, there could be a colleague well-versed in a skill of knowledge realm, that would be advantageous to your career.
  • Take the time to focus on people. Jill point out that, “Regardless of the subject matter, building relationships will always help to drive a career forward. In moments of stand-still, maximize relationships, get to know others on a more human level by offering time and assistance. This will pay off in the end when new teams are formed and new opportunities become open in the future.” These formed bonds could carry you through a difficult impasse.
  • If all else fails, consider short-term “survival” goals. If you find yourself barely hanging on, setting shorter-term goals can help. If overwhelmed or have lost your patience, focus on getting through the week. Then the next week. Thinking longer-term may be counter-productive.

Being in a less than perfect role, doesn’t necessarily mean that you cannot continue to move forward. It simply means that you must change the lens — and utilize the time in front of you in ways that you may have not previously expected.

Of course, I’m hoping that a better fit is right ahead of you.

Dr. Marla Gottschalk is an Industrial/Organizational Psychologist. She is a charter member of the LinkedIn Influencer Program. Her thoughts on work life have appeared in various outlets including Talent Zoo, Forbes, Quartz and The Huffington Post.

An industrial manufacturer had an opening for the General Manager position at one of their flagship US facilities. The organization hired a search firm to find the best candidates and internally vetted several top contenders. They ended up hiring Fred, a well-known industry veteran who had many years of experience managing similar-sized facilities. On paper, Fred was a good fit. The organization invested considerable time and resources in his onboarding. But within eighteen months, Fred was in over his head.

What went wrong? The business was experiencing rapid growth and seismic shifts in the markets they served. General Managers were being asked to think more creatively and proactively about customer needs, the business was globalizing in response to rapid advancements in technology, and there were plans in the works to significantly expand the production capability of Fred’s site. As we listened to the story in preparation for conducting assessments to fill Fred’s open-again role, it become clear what had been overlooked in the first hiring decision.

The Best Predictor of Future Performance is…

We’ve all heard the axiom, “The best predictor of future performance is the past.” Evaluating experience and past performance is important, undoubtedly, but it is increasingly insufficient as a primary predictor of future success.

Most HR selection protocols rightly stress the importance of interviewing for the knowledge, skills and abilities (KSAs) required to drive job performance today. But how do you take into account what the job – or the entire organization – could look like tomorrow? Critical aspects of the future are unknown. Jobs and organizations shift rapidly and unpredictably.

How do you assess for what you don’t know? Even without the clearly defined KSAs that will be required in the job’s future state, you can still anticipate a candidate’s longer-term success, if you know what to look for.

Rigorously evaluating “potential” when making a hiring decision is now critical. Without it, you may find yourself with a Fred. Potential is different from one’s demonstrated behavior or current skill set. Instead, it’s about something not yet realized. Potential establishes a probability of great performance at more advanced levels of responsibility. Put another way, it is the capability to thrive in roles of greater scale and complexity than what a leader has experienced in the past.

The Four Indicators to Look Out For

Based on thorough reviews of academic research, organizational and management literature, as well as our experience assessing thousands of executives and up-and-coming leaders, we’ve determined that evaluating these four factors can help you get a good read on a candidate’s ability to stretch, adapt, and tackle increasingly difficult challenges. Further, these four indicators of potential have utility across most job families and industries.

Thinking Agility

This is about more than simply being smart; it’s the ability to demonstrate mental flexibility, see the big picture, and identify patterns within the business environment which have strategic importance.

Going back to our example, while Fred was certainly intelligent and possessed highly relevant experience, he was too operational in his focus. He struggled to get out of the fray to look across the business and spot problems while they were still on the horizon. Plus, as his facility was required to change the way it was operating, he had to rely less and less on his past experience and struggled to manage the ambiguity.

Curiosity

Being inquisitive and motivated to learn are critical elements when trying to establish someone’s potential for growth. Those high in Curiosity are hungry for feedback and motivated to put that insight into action. Indeed, research has demonstrated that curiosity promotes exposure to new and challenging opportunities, which are forerunners to learning and growth.

An important element to curiosity is the concept of learning agility. This refers to the ability and motivation to acquire knowledge and apply it. Learning agility is a cliché whose time has come, and for good reason. Given rapid expansion of disruptive technologies, the ability to quickly learn is more important than ever.

In spite of his commitment, Fred lacked the self-awareness to recognize his shortcomings, or seek out enough feedback to calibrate his perception against that of his management team. He struggled to implement the constructive feedback he was being given and didn’t make the necessary course corrections.

Leads with Purpose

There is an emerging body of literature on the power of engaging, inspiring and connecting people to a higher purpose. This means using the company’s mission to articulate his or her higher purpose and helping others do the same. This concept is consistent with Daniel’s Pink’s research: one of the biggest motivators to an employee is the desire to spend time at work in the service of something larger than ourselves. Leads with Purpose also includes one’s level of humility and social competence.

In Fred’s case, he struggled to articulate a shared sense of purpose. While he tried to make visible improvements to the operation (for example, he upgraded talent in a few key management positions), employee engagement was low. A recent study by NYU indicates that purpose-oriented workers are more likely to thrive than those who work mainly for status, pay, or an advancement because such individuals are more likely to stay engaged, perform, and to lead.

Fred was so immersed in the details of managing change that he failed to connect with his employees. As a result, morale remained low and the safety culture within the facility began to deteriorate. This trend is consistent with research on the relationship between employee engagement and performance in manufacturing, where disengaged workers have 37 percent higher absenteeism, 49 percent more accidents and 60 percent more errors and defects.

Drive

This refers to one’s level of perseverance, resilience, and motivation to achieve. Of the four indicators of potential, Drive may be the most widely used measure to predict leadership potential. In our experience, having passion, energy, and drive are crucial to the emergence of successful leadership, but by itself, it’s not always enough.

Drive was an indicator Fred had in large quantities. He had an unrelenting motivation to achieve and be successful. He was energized by new assignments and overcoming obstacles. Perhaps his strength in this area led the organization to incorrectly assume he possessed the necessary potential during the hiring process. Unfortunately, his deficiencies in the other indicators ultimately contributed to his downfall.

Strength in One Potential Indicator is Not Enough

It’s worth nothing again that Fred would be evaluated very highly on one of the indicators – Drive – but possessing the skills and abilities of one indicator is not enough. The four indicators work together, and the overpowering presence of one should not be mistaken as indicative of general potential. Thinking Agility, Curiosity, Leading with Purpose, and Drive are all necessary components to thrive in increasingly complex and uncertain futures.

Improving your hiring decisions by looking to the future

We’ve found that individuals who score highly on all four of these factors demonstrate the best potential for growth and are more likely to be successful at the next level, or when the role they’re in changes in scope.

When evaluating a candidate for any position in the organization we recommend focusing on the ability to:

1) Manage increasing levels of complexity and speed when making decisions through Thinking Agility,

2) Be open to feedback and apply learning in novel situations as a result of Curiosity,

3) Inspire, empower, and help others gain a sense of personal fulfillment in their work by Leading with Purpose,

4) Demonstrate high levels of resilience and determination to achieve difficult goals through Drive.

While carefully taking into account past performance and current levels of competence relative to the demands of the job are important components of a hiring decision, it only gives you a partial picture when trying to predict job success. A candidate’s ability to quickly adapt and respond to changes in the workplace is critical in today’s complex environment.

When the manufacturing organization filled the General Manager role, they selected a candidate who showed up well both with past experience and potential, and the organization is feeling confident in that their new hire will bring long-term success. More fully assessing the candidate’s capacity for learning and growth by evaluating against the four indicators will help organizations avoid costly hiring mistakes.

Posted by: lrrp | May 31, 2018

Winng men’s Confidence

In some recent blog posts, we’ve explained why we believe it’s crucial to adopt a four‑tier application architecture in which applications are developed and deployed as sets of microservices. It’s becoming increasingly clear that if you keep using development processes and application architectures that worked just fine ten years ago, you simply can’t move fast enough to capture and hold the interest of mobile users who can choose from an ever‑growing number of apps.

Switching to a microservices architecture creates exciting opportunities in the marketplace for companies. For system architects and developers, it promises an unprecedented level of control and speed as they deliver innovative new web experiences to customers. But at such a breathless pace, it can feel like there’s not a lot of room for error. In the real world, you can’t stop developing and deploying your apps as you retool the processes for doing so. You know that your future success depends on transitioning to a microservices architecture, but how do you actually do it?

Netflix_Logo_Digital+VideoFortunately for us, several early adopters of microservicesare now generously sharing their expertise in the spirit of open source, not only in the form of published code but in conference presentations and blog posts. Netflix is a leading example. As the Director of Web Engineering and then Cloud Architect, Adrian Cockcroft oversaw the company’s transition from a traditional development model with 100 engineers producing a monolithic DVD‑rental application to a microservices architecture with many small teams responsible for the end‑to‑end development of hundreds of microservices that work together to stream digital entertainment to millions of Netflix customers every day. Now a Technology Fellow at Battery Ventures, Cockcroft is a prominent evangelist for microservices and cloud‑native architectures, and serves on the NGINX Technical Advisory Board.

In a two‑part series of blog posts, we’ll present top takeaways from two talks that Cockcroft delivered last year, at the first annual NGINX conference in October and at a Silicon Valley Microservices Meetup a couple months earlier. (The complete video recordings are also well worth watching.)

What is a Microservices Architecture?

Cockcroft defines a microservices architecture as a service‑oriented architecture composed of loosely coupled elements that have bounded contexts.

Loosely coupled means that you can update the services independently; updating one service doesn’t require changing any other services. If you have a bunch of small, specialized services but still have to update them together, they’re not microservices because they’re not loosely coupled. One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it.

The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans. A microservice with correctly bounded context is self‑contained for the purposes of software development. You can understand and update the microservice’s code without knowing anything about the internals of its peers, because the microservices and its peers interact strictly through APIs and so don’t share data structures, database schemata, or other internal representations of objects.

If you’ve developed applications for the Internet, you’re already familiar with these concepts, in practice if not by name. Most mobile apps talk to quite a few backend services, to enable its users to do things like share on Facebook, get directions from Google Maps, and find restaurants on Foursquare, all within the context of the app. If your mobile app were tightly coupled with those services, then before you could release an update you would have to talk to all of their development teams to make sure that your changes aren’t going to break anything.

When working with a microservices architecture, you think of other internal development teams like those Internet backends: as external services that your microservice interacts with through APIs. The commonly understood “contract” between microservices is that their APIs are stable and forward compatible. Just as it’s unacceptable for the Google Maps API to change without warning and in such a way that it breaks its users, your API can evolve but must remain compatible with previous versions.

Best Practices for Designing a Microservices Architecture

Cockcroft describes his role as Cloud Architect at Netflix not in terms of controlling the architecture, but as discovering and formalizing the architecture that emerged as the Netflix engineers built it. The Netflix development team established several best practices for designing and implementing a microservices architecture.

Create a Separate Data Store for Each Microservice

Do not use the same backend data store across microservices. You want the team for each microservice to choose the database that best suits the service. Moreover, with a single data store it’s too easy for microservices written by different teams to share database structures, perhaps in the name of reducing duplication of work. You end up with the situation where if one team updates a database structure, other services that also use that structure have to be changed too.

Breaking apart the data can make data management more complicated, because the separate storage systems can more easily get out sync or become inconsistent, and foreign keys can change unexpectedly. You need to add a tool that performs master data management (MDM) by operating in the background to find and fix inconsistencies. For example, it might examine every database that stores subscriber IDs, to verify that the same IDs exist in all of them (there aren’t missing or extra IDs in any one database). You can write your own tool or buy one. Many commercial relational database management systems (RDBMSs) do these kinds of checks, but they usually impose too many requirements for coupling, and so don’t scale.

Keep Code at a Similar Level of Maturity

Keep all code in a microservice at a similar level of maturity and stability. In other words, if you need to add or rewrite some of the code in a deployed microservice that’s working well, the best approach is usually to create a new microservice for the new or changed code, leaving the existing microservice in place. [Editor – This is sometimes referred to as the immutable infrastructure principle.] This way you can iteratively deploy and test the new code until it is bug free and maximally efficient, without risking failure or performance degradation in the existing microservice. Once the new microservice is as stable as the original, you can merge them back together if they really perform a single function together, or if there are other efficiencies from combining them. However, in Cockcroft’s experience it is much more common to realize you should split up a microservice because it’s gotten too big.

Do a Separate Build for Each Microservice

Do a separate build for each microservice, so that it can pull in component files from the repository at the revision levels appropriate to it. This sometimes leads to the situation where various microservices pull in a similar set of files, but at different revision levels. That can make it more difficult to clean up your codebase by decommissioning old file versions (because you have to verify more carefully that a revision is no longer being used), but that’s an acceptable trade‑off for how easy it is to add new files as you build new microservices. The asymmetry is intentional: you want introducing a new microservice, file, or function to be easy, not dangerous.

Deploy in Containers

Deploying microservices in containers is important because it means you just need just one tool to deploy everything. As long as the microservice is in a container, the tool knows how to deploy it. It doesn’t matter what the container is. That said, Docker seems very quickly to have become the de facto standard for containers.

Treat Servers as Stateless

Treat servers, particularly those that run customer‑facing code, as interchangeable members of a group. They all perform the same functions, so you don’t need to be concerned about them individually. Your only concern is that there are enough of them to produce the amount of work you need, and you can use autoscaling to adjust the numbers up and down. If one stops working, it’s automatically replaced by another one. Avoid “snowflake” systems in which you depend on individual servers to perform specialized functions.

Cockcroft’s analogy is that you want to think of servers like cattle, not pets. If you have a machine in production that performs a specialized function, and you know it by name, and everyone gets sad when it goes down, it’s a pet. Instead you should think of your servers like a herd of cows. What you care about is how many gallons of milk you get. If one day you notice you’re getting less milk than usual, you find out which cows aren’t producing well and replace them.

Netflix Delivery Architecture is Built on NGINX

Netflix is a longtime user of the open source NGINX software and became the first customer of NGINX, Inc. after it incorporated in 2011. Indeed, Netflix chose NGINX as the heart of its delivery infrastructure, Open Connect, one of the largest content delivery networks (CDNs) in the world. With the ability to serve thousands, and sometimes millions, of requests per second, NGINX and NGINX Plus are optimal solutions for high‑performance HTTP delivery and enable companies like Netflix to offer high‑quality digital experiences to millions of customers every day.

One of the common interview question is ‘What are differences between Comparator and Comparable’. or ‘How will you sort collection of employee objects by its id or name’.For that we can use two interfaces.i.e. Comparator and Comparable.Before we actually see differences,let me give you brief introduction of both.

Comparable interface: Class whose objects to be sorted must implement this interface.In this,we have to implement compareTo(Object) method.

For example:

1 public class Country implements Comparable{
2        @Override
3     public int compareTo(Object arg0) {
4         Country country=(Country) arg0;
5         return (this.countryId < country.countryId ) ? -1: (this.countryId > country.countryId ) ? 1:0 ;
6 }}

If any class implements comparable inteface then collection of that object can be sorted automatically using Collection.sort() or Arrays.sort().Object will be sort on the basis of compareTo method in that class.

Objects which implement Comparable in java can be used as keys in a SortedMap like TreeMap or SortedSet like TreeSet without implementing any other interface.

Comparator interface: Class whose objects to be sorted do not need to implement this interface.Some third class can implement this interface to sort.e.g.CountrySortByIdComparator class can implement Comparator interface to sort collection of country object by id. For example:

1 public class CountrySortByIdComparator implements Comparator<Country>{
2
3     @Override
4     public int compare(Country country1, Country country2) {
5
6         return (country1.getCountryId() < country2.getCountryId() ) ? -1: (country1.getCountryId() > country2.getCountryId() ) ? 1:0 ;
7     }
8
9 }

Using Comparator interface,we can write different sorting based on different attributes of objects to be sorted.You can use anonymous comparator to compare at particular line of code. For example:

01         Country indiaCountry=new Country(1'India');
02         Country chinaCountry=new Country(4'China');
03         Country nepalCountry=new Country(3'Nepal');
04         Country bhutanCountry=new Country(2'Bhutan');
05
06         List<Country> listOfCountries = new ArrayList<Country>();
07         listOfCountries.add(indiaCountry);
08         listOfCountries.add(chinaCountry);
09         listOfCountries.add(nepalCountry);
10         listOfCountries.add(bhutanCountry);
11
12 //Sort by countryName
13
14            Collections.sort(listOfCountries,new Comparator<Country>() {
15
16                @Override
17                public int compare(Country o1, Country o2) {
18
19                    return o1.getCountryName().compareTo(o2.getCountryName());
20                }
21            });

Comparator vs Comparable

Parameter Comparable Comparator
Sorting logic Sorting logic must be in same class whose objects are being sorted. Hence this is called natural ordering of objects Sorting logic is in separate class. Hence we can write different sorting based on different attributes of objects to be sorted. E.g. Sorting using id,name etc.
Implementation Class whose objects to be sorted must implement this interface.e.g Country class needs to implement comparable to collection of country object by id Class whose objects to be sorted do not need to implement this interface.Some other class can implement this interface. E.g.-CountrySortByIdComparator class can implement Comparator interface to sort collection of country object by id

Sorting method
int compareTo(Object o1)
This method compares this object with o1 object and returns a integer.Its value has following meaning
1. positive – this object is greater than o1
2. zero – this object equals to o1
3. negative – this object is less than o1
int compare(Object o1,Object o2)
This method compares o1 and o2 objects. and returns a integer.Its value has following meaning.
1. positive – o1 is greater than o2
2. zero – o1 equals to o2
3. negative – o1 is less than o1
Calling method Collections.sort(List)
Here objects will be sorted on the basis of CompareTo method
Collections.sort(List, Comparator)
Here objects will be sorted on the basis of Compare method in Comparator
Package Java.lang.Comparable Java.util.Comparator

Java code: 
For Comparable: We will create class country having attribute id and name.This class will implement Comparable interface and implement CompareTo method to sort collection of country object by id.

1. Country.java

01 package org.arpit.javapostsforlearning;
02 //If this.cuntryId < country.countryId:then compare method will return -1
03 //If this.countryId > country.countryId:then compare method will return 1
04 //If this.countryId==country.countryId:then compare method will return 0
05 public class Country implements Comparable{
06     int countryId;
07     String countryName;
08
09     public Country(int countryId, String countryName) {
10         super();
11         this.countryId = countryId;
12         this.countryName = countryName;
13     }
14
15     @Override
16     public int compareTo(Object arg0) {
17         Country country=(Country) arg0;
18         return (this.countryId < country.countryId ) ? -1: (this.countryId > country.countryId ) ? 1:0 ;
19     }
20
21     public int getCountryId() {
22         return countryId;
23     }
24
25     public void setCountryId(int countryId) {
26         this.countryId = countryId;
27     }
28
29     public String getCountryName() {
30         return countryName;
31     }
32
33     public void setCountryName(String countryName) {
34         this.countryName = countryName;
35     }
36
37 }

2.ComparatorMain.java

01 package org.arpit.javapostsforlearning;
02
03 import java.util.ArrayList;
04 import java.util.Collections;
05 import java.util.List;
06
07 public class ComparatorMain {
08
09     /**
10      * @author Arpit Mandliya
11      */
12     public static void main(String[] args) {
13          Country indiaCountry=new Country(1'India');
14          Country chinaCountry=new Country(4'China');
15          Country nepalCountry=new Country(3'Nepal');
16          Country bhutanCountry=new Country(2'Bhutan');
17
18             List<Country> listOfCountries = new ArrayList<Country>();
19             listOfCountries.add(indiaCountry);
20             listOfCountries.add(chinaCountry);
21             listOfCountries.add(nepalCountry);
22             listOfCountries.add(bhutanCountry);
23
24             System.out.println('Before Sort  : ');
25             for (int i = 0; i < listOfCountries.size(); i++) {
26                 Country country=(Country) listOfCountries.get(i);
27                 System.out.println('Country Id: '+country.getCountryId()+'||'+'Country name: '+country.getCountryName());
28             }
29             Collections.sort(listOfCountries);
30
31             System.out.println('After Sort  : ');
32             for (int i = 0; i < listOfCountries.size(); i++) {
33                 Country country=(Country) listOfCountries.get(i);
34                 System.out.println('Country Id: '+country.getCountryId()+'|| '+'Country name: '+country.getCountryName());
35             }
36     }
37
38 }

Output:

01 Before Sort  :
02 Country Id: 1||Country name: India
03 Country Id: 4||Country name: China
04 Country Id: 3||Country name: Nepal
05 Country Id: 2||Country name: Bhutan
06 After Sort  :
07 Country Id: 1|| Country name: India
08 Country Id: 2|| Country name: Bhutan
09 Country Id: 3|| Country name: Nepal
10 Country Id: 4|| Country name: China

For Comparator: We will create class country having attribute id and name and will create another class CountrySortByIdComparator which will implement Comparator interface and implement compare method to sort collection of country object by id and we will also see how to use anonymous comparator.

1.Country.java

01 package org.arpit.javapostsforlearning;
02
03 public class Country{
04     int countryId;
05     String countryName;
06
07     public Country(int countryId, String countryName) {
08         super();
09         this.countryId = countryId;
10         this.countryName = countryName;
11     }
12
13     public int getCountryId() {
14         return countryId;
15     }
16
17     public void setCountryId(int countryId) {
18         this.countryId = countryId;
19     }
20
21     public String getCountryName() {
22         return countryName;
23     }
24
25     public void setCountryName(String countryName) {
26         this.countryName = countryName;
27     }
28
29 }

2.CountrySortbyIdComparator.java

01 package org.arpit.javapostsforlearning;
02
03 import java.util.Comparator;
04 //If country1.getCountryId()<country2.getCountryId():then compare method will return -1
05 //If country1.getCountryId()>country2.getCountryId():then compare method will return 1
06 //If country1.getCountryId()==country2.getCountryId():then compare method will return 0
07  public class CountrySortByIdComparator implements Comparator<Country>{
08
09     @Override
10     public int compare(Country country1, Country country2) {
11
12         return (country1.getCountryId() < country2.getCountryId() ) ? -1: (country1.getCountryId() > country2.getCountryId() ) ? 1:0 ;
13     }
14
15 }

3.ComparatorMain.java

01 package org.arpit.javapostsforlearning;
02
03 import java.util.ArrayList;
04 import java.util.Collections;
05 import java.util.Comparator;
06 import java.util.List;
07
08 public class ComparatorMain {
09
10     /**
11      * @author Arpit Mandliya
12      */
13     public static void main(String[] args) {
14          Country indiaCountry=new Country(1'India');
15          Country chinaCountry=new Country(4'China');
16          Country nepalCountry=new Country(3'Nepal');
17          Country bhutanCountry=new Country(2'Bhutan');
18
19             List<Country> listOfCountries = new ArrayList<Country>();
20             listOfCountries.add(indiaCountry);
21             listOfCountries.add(chinaCountry);
22             listOfCountries.add(nepalCountry);
23             listOfCountries.add(bhutanCountry);
24
25             System.out.println('Before Sort by id : ');
26             for (int i = 0; i < listOfCountries.size(); i++) {
27                 Country country=(Country) listOfCountries.get(i);
28                 System.out.println('Country Id: '+country.getCountryId()+'||'+'Country name: '+country.getCountryName());
29             }
30             Collections.sort(listOfCountries,new CountrySortByIdComparator());
31
32             System.out.println('After Sort by id: ');
33             for (int i = 0; i < listOfCountries.size(); i++) {
34                 Country country=(Country) listOfCountries.get(i);
35                 System.out.println('Country Id: '+country.getCountryId()+'|| '+'Country name: '+country.getCountryName());
36             }
37
38             //Sort by countryName
39             Collections.sort(listOfCountries,new Comparator<Country>() {
40
41                 @Override
42                 public int compare(Country o1, Country o2) {
43                     return o1.getCountryName().compareTo(o2.getCountryName());
44                 }
45             });
46
47             System.out.println('After Sort by name: ');
48             for (int i = 0; i < listOfCountries.size(); i++) {
49                 Country country=(Country) listOfCountries.get(i);
50                 System.out.println('Country Id: '+country.getCountryId()+'|| '+'Country name: '+country.getCountryName());
51             }
52     }
53
54 }

Output:

01 Before Sort by id :
02 Country Id: 1||Country name: India
03 Country Id: 4||Country name: China
04 Country Id: 3||Country name: Nepal
05 Country Id: 2||Country name: Bhutan
06 After Sort by id:
07 Country Id: 1|| Country name: India
08 Country Id: 2|| Country name: Bhutan
09 Country Id: 3|| Country name: Nepal
10 Country Id: 4|| Country name: China
11 After Sort by name:
12 Country Id: 2|| Country name: Bhutan
13 Country Id: 4|| Country name: China
14 Country Id: 1|| Country name: India
15 Country Id: 3|| Country name: Nepal

 

Posted by: lrrp | April 25, 2018

Observe well….

Agile companies believe that teamwork is essential to delivering working software, and that great Agile teams are about “we” rather than “I.” Unfortunately, many companies claim they have an Agile team, but in reality they don’t. It’s important to learn what an Agile team really is, and to find ways to build them within your own company.

It takes a while to transform a group of people into a real Agile team. However, it pays off later on, as Agile project management brings a lot of value to the team and to the client.

Let me just mention the most common Agile benefits: 93 percent of teams said Agile helped them improve speed to market, 93 percent said it helped them switch gears more quickly and effectively, 87 percent said it helped them to be more productive, 80 percent said Agile led to enhanced prioritization of the things that matter, and 80 percent said adopting Agile helped them deliver a better and more relevant end product.

One of the key success factors is to provide continuous mentoring and shared skill sets.

When team members learn from each other, it makes the process of Agile transformation much easier and more pleasant.

Qualities of an Agile Team

More than anything, teams should understand that change is inevitable. Being able to adapt to rapidly changing circumstances is key for Agile development and Agile project management.

Able to Incorporate Feedback Quickly

This change most often comes from receiving and giving feedback. Feedback is one of the essential parts of Agile development. It doesn’t matter how fast you can deliver the desired product or feature; if it is not in demand anymore, everything that the team has done may simply go to a rubbish bin. And unfortunately, that happens a lot in software development.

How does it feel when you actually face a situation where a project you have been working on for some time won’t be published or used? It’s very frustrating and disappointing.

So, in order to be on track with your stakeholders, you need to constantly communicate with them; therefore, feedback is highly related to internal and external communication.

But for Agile teams, you can’t just listen to the feedback. You also need to incorporate it quickly. Feedback, in an Agile sense, is about short-term advances.

Normally, we are talking about two-week sprints—optimal time to code, test, and get feedback on the most important functionality. It also helps to launch quality minimum viable product faster and get return on investment faster.

Work Together as a Team

There is a very good saying: “If you want to go fast, go alone. If you want to go far, go together.” And in Agile software development, this is crucial. You learn from your peers even more than from books and courses.

A very important part of building an Agile team is to empower the team to work independently.

Not only does this give all the team members a sense of belonging and ownership, it also shows trust and respect.

At the end of each sprint, there are always features that you need to deliver. When teams work using Scrum methodology, they have user stories; tickets they need to move from “to do” to “done.” And when all of them are on the stage “done,” it motivates team members, as they can actually see the result of what they are working on. By placing more emphasis on the results, team members feel empowered to make decisions, solve problems, and develop innovative solutions.

Goals in every Agile team are different. At Apiumhub, we put working software over a number of functionalities, always doing test-driven development (TDD) and continuous integration (CI). Having goals helps Agile teams see the progress and move forward in the right way.

The best way to help make these goals clear is having a product owner role on an Agile team. I strongly believe that it is a must nowadays. The product owner is responsible for the business direction of the product, and they are responsible for creating and prioritizing the user stories. The development team is responsible for the technical direction of the product, and the tech team will actually deliver these user stories.

However, it is important to note that the product owner always takes into account the feedback of the tech team regarding the priorities of user stories.

Be Organized and Use Tools

Being Agile is about efficiency and automation. The fewer manual tasks that are done, the better. That means that using such tools as Jira is a big must. You can find other Agile project management tools here. Being Agile also means having several important meetings during the sprint: sprint planning, sprint review, sprint retrospective, and, of course, daily standups. Having meetings often means that there is a higher likelihood that everyone understands their role and what they need to achieve.

Each Agile team has its own definition of “done.” But every Agile team needs to agree on what they consider to be “done.” It is key to delivering high-quality products and satisfying your stakeholders in terms of project management and results, and functionalities and quality. Basically, it is a checklist of features and activities that adds or demonstrates value and that needs to be completed.

As we mentioned in the beginning of the article, unfortunately, many teams try to be Agile, but they fail. In the software development world, based on our experience, it’s very important to learn best practices, and to be truly Agile, you must practice TDD, CI, and unit testing.

There are actually common stages that the team goes through to become an Agile team. Let’s look at them.

How To Build an Agile Team

Creating an Agile team takes time, and members often go through different stages from being just a group of people to an Agile team with common goals and right processes. I don’t want to reinvent the wheel here; let me just share with you Bruce Tuckman’s stages, highlighting the important things to better understand them. They will definitely help you make your team more effective.

Forming Stage

The first stage is the forming stage, which is very similar to orientation day at universities. It is essential and helps people get to know each other, find useful information, and write down the rules. This stage is about focusing on defining and assigning tasks, establishing a schedule, organizing the team’s work, etc.

Storming Stage

Being on a team is like being in a relationship. At first, you may think that a person is perfect, but then you realize they actually are not. And then you either learn to manage the relationship or it will end quickly. This stage is also about goals and guidelines that each team should follow to be on the same wavelength and achieve the common goal. In this stage, teams brainstorm ideas to find solutions to the issues they have.

Norming Stage

In this stage, team members develop their purpose and strategy for achieving their goals. This is when everyone is focused on developing shared values and determining ways to best work together. People start to notice and appreciate their team members’ strengths and everyone contributes and works as a cohesive unit.

Performing Stage

In this stage, team members are confident, motivated, and able to easily work together on interdependent tasks. It also gets easy for them to communicate and coordinate with each other in an effective manner. Basically, the fourth stage is the one that all Agile teams strive to reach.

Team-Building Activities for a More Agile Team

Games are fun and they are very effective for team building. Here are some examples of the games that are quite short, but very effective. Let’s look at the most famous ones:

Buy a Feature

This game teaches feature prioritization and it takes around 15 minutes to play. The optimal number of people for groups is three to eight. Each player receives two items: a handout with a menu of features and their prices, and a sum of play money.

Features can be anything, for example: items to have on a vacation. The sum total of all players’ money should be less than the total of all feature prices. This introduces scarcity and forces the team to make trade-offs, because it’s not possible to purchase all items on the list.

Players take turns using their individual sums of money to pay for features they find most valuable. Once players have spent most of their funds, and either they don’t have enough individually to make another purchase or they don’t value what’s left on the menu to buy anything else, the group will pool the remaining funds and discuss what to buy from the remaining items. This game helps team members to learn how to prioritize user stories and how to do resource management.

The White Elephant Sizing

In all software projects, Agile teams need to estimate user stories as well as product backlog. And this game is fantastic to learn how to estimate user stories. In this Agile game, players have 50 user stories and have four hours to estimate them. Everyone’s voices are heard, and everyone contributes equally.

The goal of this game is to get a quick estimate of the size of an Agile project and the size of the individual stories before the project starts. I believe this game is absolutely a must, as most Agile teams have issues with estimating their projects in terms of time.

Battleships

This Agile game is generally used to introduce people to iterative development and to explain the concepts behind it. The idea is to get people to understand that up-front, large plans are just not a good idea!

In this game, you have two teams: A and B. Each will have a “battleships sheet” and some dots. Each team will have around two minutes to plan how they would like to place their ships. Team A will have five minutes to plan its hits up front and will mark them on their sheet, and will then communicate them to Team B, which will tell Team A which ships sunk, hits that missed, etc. Team B then also gets five minutes to play each one of their hits, but this time with real-time feedback from Team A on misses, hits, and ships that sunk.

Results are obvious. Team B gets the chance to change its plans due to the fact that they follow iterative rules, which will make them score higher. It seems obvious in this game; however, many teams forget it when they work on real projects.

The Ball Point Game

This game helps a lot when introducing Scrum to new Agile teams. It helps to estimate user stories, sprint, and the project overall.

The rules are simple: You need to give the team as many balls as possible in two minutes. Each ball has to pass by each team member. In order to get a point, it’s important that the first person who gets the ball be the last one to touch it. So the team will get five iterations, and before each one, it has to estimate how many balls they believe will be passed. Then, the actual number is recorded at the end of each iteration and is compared with the estimations given by the team.

Often, at the first iteration, it is very difficult to give an estimation, as the team doesn’t really know how long it may take to get one ball through the whole team. But, after each iteration, there are retrospectives, and therefore the team adapts the process. With each iteration, normally, the results become better and better. This game helps Agile teams work together and learn how to make estimations, taking into account not only personal capabilities, but also capabilities of the team as a whole. Also, it helps to understand the need for iterative progress and development.

Build an Agile Team to Streamline Software Development

Statistics say that by using Agile project management, on average, the time to market is 37 percent faster and the efficiency of an Agile team is increased by 16 percent.

Switching to Agile is a great idea and I really hope this article gave you a good overview of what it is and how you can master it. And if you know other interesting Agile games, feel free to share them in the comments section below.

A blog is useful for many reasons. It can become a source of leads, it can be the place where, in the future, you might sell your products if you want to become an indie developer, or it can simply be the place where you have your audience and express your ideas.

I’ve been blogging for more than 11 years now, more or less consistently — although sometimes I stopped for too long. I recently revamped the blog and started to write consistently — very consistently — to the point I now write every single day of the week. I’ve already seen a lot of good results. Here are my thoughts on blogging, why I think every developer should blog, and blog consistently.

A few things I want you to forget

“I am not an expert”

Anyone has a unique angle, a perspective on something that’s worth sharing. You might think you don’t know as much as person X, but person Y might have much less experience than you and would benefit from reading your thoughts and learnings.

Also, the best moment to teach something is right after you’ve learned it, because you remember how not knowing about it feels.

In this case, you can blog with the tone of a student that’s just learned something. I learn new things every day. Around 50% of what I end up writing I just learned while researching a topic.

“I’m not a good writer”

I’m not either, but I don’t care.

Just remember: you will never become a good writer unless you practice writing every day for years. You will become a good writer, eventually.

“I fear criticism”

It’s true that some places on the internet are not afraid to give harsh opinions on things, notoriously Reddit and Hacker News — but this is a good thing.

Remember, you’re not growing if you’re not challenged. Also, you’re not required to post there if you don’t want to. Do you worry about someone making a mean comment on a post that’s controversial? Remove comments altogether.

Why writing is great for a developer

One of ways I learn best is by doing. I literally decide on a topic I think I know something about, and I drill down in a spiral loop through things I didn’t know, or I didn’t even think about.

They say you never fully understand a topic until you are able to explain it. Blogging is a low barrier to explaining things.

Kick start your career

I’ve kick started my career in software thanks to a blog.

It was 2007, and I’d started sharing little things I was learning while building a few web applications as part of my university program.

Through this blog, I got a lot of connections and leads for an upcoming freelance and contractor career.

That old blog has since died off — I stopped writing on it a long time ago and the content, now completely outdated, is long gone. But without it, I think I would have never imagined opening my own business right out of school.

Switch gears or technology stack

I did this a few times with my blog writing. If I am into one kind of technology stack, and I find myself interested in something else, I write several posts about it.

For example, last summer I got deep into Go programming for two months. And I literally had recruiters sending me job offers I’d never applied to, just because they found my posts shared online.

Some key aspects of a successful technical blog

Be consistent with the topic

I never subscribe to feeds of blogs that are not focused on something. In my case I talk Frontend Development, and I subscribe to other frontend development blogs.

And even though I talked a lot about Go last summer, it was still interesting to frontend developers as well (learn Go if you have a chance, it’s refreshing). Don’t just rant about everything that comes to mind. Keep it professional.

Show up consistently

If you set out to write a blog post every week, do it. Twice a week, much better. I write every day, because I know that if I allow some day to slip by, I will allow myself to skip another day, and so on until I won’t post any more.

Write posts in advance

Don’t write the blog post the day you want to publish it. Write it one week in advance, or more. You are less likely to miss a blog post day even if you take a few days off, or you’re sick.

It’s also a good idea to publish them in advance. WordPress makes it very easy, and it’s doable also with static blogs (here’s how I do it with Netlify and Hugo). Schedule a specific time and day to write, consistently.

Have a list of post ideas

James Altucher says to write down 10 ideas every day. That’s 3,650 ideas a year. At least a few of those will be good ideas.

The same goes for blog posts titles and topics. Have a list of blog post ideas. When you feel inspired to write, you will have an argument perfect for that day.

Read books. Read blog posts. Read Twitter. Listen to podcasts

Keep you up to date with the topics that you want to write about. I write about software development, and Twitter is a never-ending source of great ideas for topics. The same goes for books and blogs. Medium is amazing for this.

Podcasts are different because you listen to them, and I always have one on while driving or when I take half a day off to go walk the dogs out in nature.

Wake up early

Set the alarm clock, actually wake up, and start writing. I used to wake up at 8AM — since I never had any commute to take (I only work remotely), I could take it easy. I now wake up at 6AM, and by 8AM I have a new post scheduled for the next week. When you have accomplished a task such as creating a new blog post by 8AM, you feel super energized to tackle the rest of the day. Wake up even earlier if you can (I can’t, or I’ll spend the rest of the day in zombie-state).

Block distractions

When researching on the web to write a blog post, it’s incredibly easy to jump into distracting places. I block them with SelfControl on my Mac, and I can’t disable the blocker.

Write on your own platform

Write on your own platform. Write on your own platform. Write on your own platform. Use other’s platforms to get more reach. Play the long game. Every blog post you write could be worth thousands of visitors in the next 10 years. Maybe not, but maybe the next hit that Google will like the most and put #1 is the next post you will write.

Don’t just write exclusively on other people’s platforms: you don’t own them, and they could even go out of business (happens all the time) or shut down the service, and you will lose it all.

Have an audience

This goes hand in hand with the previous point. If you’re just starting out, you might get 10 visitors a day if you actively share your posts (unless you hit it big on some sharing platform like Reddit or Hacker News).

Consistent traffic comes from search engines, but this is a very, very long game to play, and it’s easy to be discouraged if you write with passion but no one reads your posts.

So, look for an audience. Write on your own blog, import your posts to Medium (so it adds a canonical tag and you won’t make Google angry for duplicate content), and try to get it published on a big publication. Publications are eager for content, they have an audience to satisfy, and they are looking for you. Having an early audience will boost your enthusiasm and determination. Link back to your blog.

Promote your content

When you hit “publish,” you’ve done 50% of the work: you have your idea, you’ve done your topic research along with the actual writing, you’ve looked for typos, you’ve found a nice picture…and now you need to promote your writing. Post on Twitter if you have a following. Find other ways to “show up.”
Some locations might welcome your self-promotion, but it really depends on the place and its rules.

Your blog is your media platform

I read this quote on Hacker News a few weeks ago:

Don’t think of it as a blog. See it as your own media platform, whose only purpose is to broadcast information that drives sales — https://twitter.com/pryelluw

This advice is spot on. I saved it and I plan to read it once a month. Sales is something that might make you feel uncomfortable, but think of it as selling ideas, or selling your own expertise. Selling yourself.

Set up an email list now

Really. RSS is not dead, but is used only by a small percentage of people. You don’t own your Twitter following or your Medium following, you just own your email list. I recommend TinyLetter, it’s simple, free and amazing.

Don’t care about the design

Really. Especially if you’re not keen on design, pick the simplest theme you can find. Simple is nice and beautiful.

Your blog is not about you

Readers don’t care about you. Readers come to your blog because they hope you are going to solve a problem for them (if they came from a Google search), or because they think they will find useful information that will help them do something. Help them by writing for them.

Avoid popups and ads

Really. No popups. They don’t work if you target other developers as your readers, they are annoying, and Google might even penalize you for using them.

Also, don’t put ads on your site. They are simply bad, and unless you have thousands of visitors a day, they are not worth it.

Check your comment solution if you use a 3rd part service. A very popular one shows advertising to users not logged in to their platform, unless you pay.

Don’t let your blog collect dust

If you start out with a new blog, before even publishing one post, prepare a few posts in the pipeline.

Don’t sit on those posts for too long — prepare a queue.

Choose a schedule, stick to that, and never give up.

When you see blogs that have 3 or 4 posts per year, or abandoned blogs, it’s sad to think about the dreams the owner had when starting out. But those dreams never materialized, and the blog was left, all alone, collecting dust and getting less relevant day after day.

Don’t let your blog be one of those.

Posted by: lrrp | April 17, 2018

Perseverance…

Older Posts »

Categories