DEV Community: Ana Chiritescu

Your favorite analogies to explain IT concepts. Let's discuss!

Ana Chiritescu — Thu, 05 Oct 2017 19:35:41 +0000

Since my previous post on suggestions around best way to explain APIs to a non-technical audience, I gave an in-company talk on upcoming features on the technology I am currently working with (MuleSoft).

The great replies received in the last post inspired me and I already started applying some of the suggestions.
This brings me back to the fact that the easiest way to connect with your audience and have them easily understand concepts that otherwise would seem difficult to grasp is to use analogies with which they can easily relate. The discussion becomes more appealing and at the same time easier to follow.

The most recent analogy I read about and also used, is related to explaining how streaming consumption works.

There are two main challenges when consuming a stream:

it can only be read once
it cannot be read in parallel

Think of a pint of beer, each sip you take is one sip you cannot take again. Similarly, if two people use two straws to sip from the same pint, none of them will ever drink the full pint.

Do you have preferred analogies to explain complex IT concepts? Curious to hear your thoughts around this! :-)

APIs for dummies. Let's discuss!

Ana Chiritescu — Fri, 22 Sep 2017 16:04:07 +0000

I was recently asked to be a speaker at a first meetup organized by a group of enthusiastic women that indirectly work with IT, understand that IT is becoming the core of everything we do and would like to learn more about this.

My plan is to talk about IT Systems, the importance of Integration and APIs.

Do you have any suggestions on how to best explain these concepts and/or talks/articles around it?

Moreover, depending on the time allocated for the talk, I might also go for a lightweight demo. The programming laguage used should be something super simple and friendly for non-techincal eyes! Any ideas?

Thanks a million for your comments! ðŸ˜Š

It's a fact: great teams have great leaders.

Ana Chiritescu — Sat, 16 Sep 2017 12:08:08 +0000

This week at work there have been multiple discussions around great teams and with that, about my team. This is why I decided to write some thoughts around it.

I have been working in IT for almost 11 years, in 3 countries with colleagues from all over the world. This means that in a rather short time I had the luxury to learn a lot about work environments, various cultures and I also ran into multiple challenges which most probably only occur in such environments.

Even more important, I had the tremendous luck to work with and have as mentors colleagues that are among the best in their field, who also enjoyed helping others grow. With this I noticed a trend: great teams, have great leaders.

Short and sweet: teams are made of people, people are different, follow their own career path and go through various stages in their lives. On top of this, there is the human nature factor: some of us are more competitive than others, some would prioritize higher their own needs and success compared to team's needs and success and so on.

With all these differences and challenges, there are still great teams out there.

What do these teams do differently?

They respect each other.
They learn to be good listeners and take into account everyone's opinion.
They take responsibility for both their successes and failures.
They trust each other.
They believe that knowledge sharing will not make you irreplaceable, but it will help both you and the team evolve.
They are not afraid to ask for help.
They do not let conflicts go undiscussed, but bring these out in the open and talk it through.
They regularly pause and reflect on how things are progressing and look into what should be improved next.
They have good sense of humor that keeps morale up also during hard times.
They are happy and supportive of a colleague's success.
And they do not forget to also have fun and celebrate achievements.

Where do the team leaders fit in? They are the ones that nurture the team by encouraging the values derived from above items.

And let me tell you, it can sometimes be an extremely bumpy ride and this is when you know that change is happening! :-)

What do you think makes a team great?

I would love to hear your thoughts and comments around this.

Never underestimate the power of best practice

Ana Chiritescu — Mon, 24 Jul 2017 21:02:50 +0000

I see best practices as special recipes created after doing the same thing over and over again by mixing various ingredients in various ways until you get an outcome easily reproducible (standard) and of superior quality.

Let’s look at the following scenario of an endless loop and options to solve it by applying the right ingredients:

Use case prerequisite

The message published on the queue is invalid
The exception thrown by the receiver that picked up the message for processing, is not caught in the catch block

Use case description

A requestor publishes an invalid message to a message channel (queue).
There is one listener / receiver to this queue, that will get the message.

a) In case of a valid message, an acknowledgement (ACK) is sent back saying that it is now in safe hands.
b) In our case the invalid message with incorrect error handling leads to an uncaught exception and a message locked “in-flight (a message awaiting ACK or NACK) until the Default Lock TTL (time-to-live) expires (for example: 2 min)
After the 2 minutes (Lock TTL), the invalid message is made visible to other receivers. In our case, the same receiver will pick up the message and resume from 2.b)
The poisonous message will be kept on the queue for 7 days (TTL = 7 days) which gives us a nicely hidden infinite loop.

What do you do when you see that the message keeps being released on the queue and the receiver logic gets executed at a speed that only makes you happy when you are looking for fast performing systems? You of course try to solve the puzzle...

As you probably noticed from the above prerequisites there were already two major issues:

Message validation was not applied before publish to the queue
Always catch ALL exceptions, no matter what!

To err is human, hence you should always design your solution for failure.

Several suggestions:

Always use a Dead Letter Queue assigned to your processing queue so that the invalid messages are moved out to the Dead Letter Queue after a given number of retries. This way you at least shorten the life of the infinite loop.
Setup monitoring for your application / services in relation to the non-functional requirements: do you expect a load on your queue of approx. 10 messages per minute and you end up processing 2000, then most probably this requires your attention
Review your configuration settings, default is good, but custom case by case might be even better
Unit test your code, including error handling

Technology used: Anypoint MQ (MuleSoft’s cloud messaging service) and MuleESB

Hi, I'm Ana.

Ana Chiritescu — Wed, 19 Jul 2017 17:23:32 +0000

I have been working in IT for 10 years, started as a Java coder and gradually specialized in IT integration while working with webMethods and Oracle SOA 11G (not so much coding, more visual development).

2 years ago I began working with MuleSoft and that reopened my appetite for coding.

I am curious by nature and I like to keep myself busy by always learning new things. I am a strong believer that the best way to develop is to share your knowledge with the others whenever you see the opportunity.

By joining this community I hope I will be able to both contribute with useful information from my own "lessons learned" and also keep-on learning! :)

Topics of special interest:

MuleSoft
Java, Spring, Groovy
Integration Architecture, Solution Design
APIs
Continuous Delivery
git
node.js
Agile, Processes, Leadership
Innovation

You can find me on Twitter as @anachiritescu

Nice to meet you all! :)