Nov 24 2019

The last review

Category: Funny,TechnicalIuliana @ 2:41

When writing a technical book there are a few steps involved. Sure, I’m writing the text, producing the images and the code. But after that… the reviews come.

The first one is the technical review, if I am lucky I get Manuel Jordan, that is very scrupulous and very technically savvy. And he misses nothing. He corrects typos, code, asks questions and proposes changes that increase the value of a book. I’ve had other reviewers and they were not even a quarter as good as he is. So I began asking Apress for him as a reviewer for any book I write.

After Manuel is done, and I modify the chapters accordingly the grammar/expression review comes in. This is supposed to be performed my very good English/American language speakers that sometimes also use software to replace certain expressions. Reviewing my books after they do their work is the part I loathe the most. Why? Well, because they are probably not technical persons and because that software sometimes does shitty things, that they fail to notice. Also the final review that I have to do has a very tight deadline, although I have a full time job. When it comes to this review, nobody seems to care.

Anyway, this year I decided to show you a few samples of how my last review goes. So, I receive a PDF that is full of notifications regarding what was changed and with paragraphs highlighted in red, when they seem to make no sense. Every team or person that makes these reviews have their little peculiarities. In one of the previous books somebody replaced all instances of which with that. In the book I just finished reviewing these guys did the opposite.  In the previous book, one of these persons modified all the tenses of the to be verb to present tense. As you can imagine, I was not happy about it and had to review a 700 page book in a few days and correct the damage.

Seriously, I now have the impression that the grammar review is done to force me to read my own book. Because this review does the following:

  • messes up technical definitions
  • messes up some of the images by resizing them in the weirdest ways
  • splits up big phrases that make sense into smaller phrases that make no sense
  • sometimes fucks up correct grammar
  • and although there is a team of people doing this, they still managed to miss typos
  • and they missed LaTex formatting elements too

Anyway, do you want read more about my own personal 4-day hell? Here we go:

  • Apparently somebody in the team doing the review does not like the etc shortcut. Because it was replaced every where with and so forth. It’s not problem really, but it kinda adds 3 words to the book instead of one. So if the purpose is to keep the book smaller, to be (ahem!) transportable, they’ve failed.

  • Every time I introduce a piece of code or configuration, I introduce it with: You can write code like this:, or The resulting code should look like this: , etc. They hate the like this expression too. Because they always replace it with like the following. This is not a biggie either, I guess in their heads sounds more official or something, and it does not affect the technical meaning so I accept it.

  • Because the publisher is from the US, they do not like it when I use the word behaviour, because they always change it to behavior.

  • Sometimes they change words they do not recognize… just because. Somebody changed iBatis to bates, yes, like Norman Bates from Psycho.

  • Sometimes they delete the first piece of a phrase just because it mentions something from the previous section of chapter. I usually do that to continue the idea or compare it to something that I am about to introduce. Or they decide to split big phrases in smaller ones. The big ones make sense. The smaller ones, not so much. And before correcting their stuff, sometimes trying to keep the split phrasing, I just have to vent writing comments like these:Of course I delete them before I send the final document and for the moment it helps to release the stress.

  • All phrases containing any forms of [is|are|can be] used to [create| make | build] were modified to: creates, makes, builds. This has lead to the technical meaning of some things being totally trumped up. Forget about grammar being affected, the technical meaning is the one I am concerned about.

    I also have a more easier to read example:

    Microservices are a specialization and implementation approach for service-oriented architectures (SOA). They are used to build flexible, independently deployable services.


    Microservices are a specialization and implementation approach for service-oriented architectures (SOA). They build flexible, independently deployable services.

    Say what? Who does the building, the microservices? Really? How? Do they use bricks? In defence of this team, after each [is|are|can be] used to [create| make | build] I should have added [by X], where X can be the Spring Ioc Container, the developer, god… you know, the one performing the action. Because apparently when we say metal is used to make cars, it just does not make sense without mentioning who does the making.

    Also, I can’t understand the logic of these persons. If you have doubts just imagine the construction used in a daily, human phrase. Flour is used to make bread is not the same with Flour makes bread. The first makes sense. The second doesn’t.

  • Sometimes they take expressions like it is used, it is created, it is mentioned and just remove the  it is part. No idea why.

Yeah, so this was my life starting Tuesday until one hour ago when I sent the corrected PDF back to them. Finally it is over (theoretically). The book, Pivotal Certified Professional Core Spring 5 Developer Exam (I still do not know who came up with this name), is done and I can finally sleep. Maybe.


Stay safe, stay happy and stay in bed!

Oct 30 2019

How I became an AWS Certified Cloud Practitioner

Category: Funny,TechnicalIuliana @ 2:08

This will not be a technical post instructing you how to learn to pass the certification. Because I, myself I passed the exam by accident. Because I scheduled the exam by accident. But let’s go back ti the beginning.

A few years ago, 2014 or 2015, Rpx quit working for Microsoft and therefore he lost access to the VM this blog was hosted on. So, in order to keep it, I bought a Reserved Instance from Amazon and installed everything there. Why an instance in the Amazon cloud and hot a cheap special WordPress hosting service?

Because I wanted to get more comfortable with Amazon cloud. And because the only way I knew how to install & configure Apache, Mysql and WordPress, was … manually. And I liked doing it. I still like doing it, even if probably I’m not that good at it. But since moving my blog to Amazon cloud, I’ve survived two hacking attempts, me experimenting and mucking up file permissions that WordPress barely worked anymore and random MySQL failures.

When I was looking for a new job, I was not looking for a cloud engineer job. I was looking for anything that would allow me to finally make more money out of my Spring expertise. But oh well, sometimes people just click and so far I’m convinced I made the right choice.

Thus I am now starting to shift from Java/Spring expert towards … full-stack, or better said Jack-of all-trades, a title that was given to me at the beginning of my career and kinda limited my job selection at the time; because apparently it was more valuable to be an expert on a single domain, than juggling with everything. It’s quite ridiculous that after managing to finally stick to a niche for a ten years, my initial Jack-of all-trades skill might have gotten it me paid better if I would just have stuck to it. But oh well, it is what it is.

The company I currently work for is an Amazon partner, but AWS certifications expire, so after some people left the company and/or the certifications of those that stayed expired, the company found itself in danger of losing the partner status for not having enough certified AWS certified people employed. And so, the latest three people that were hired, had to become certified. I am one of those people.

So I’ve started preparing. And I panicked, because I realized I haven’t learned for an exam in … 12 years. And the information you need to accumulate to pass the certification is basically a detailed manual on how to use Amazon services wisely. And they provide a lot of services, for … well… anything. And it is not logical, it cannot be structured or organized in some programmatic way, it is not about designing or implementing anything, it’s more similar to the driving license theoretical exam. And I hate this kind of exam. My mind works very well with information that can be associated, connected to existing information that is not part of the foundation of my expertise; because the new information is connected and inferred from existing information. But the AWS training material … its very hard to associate with anything. So… I read and I wrote and watched the video training samples and still I had the impression that I am retaining … nothing.

After my much-smarter and more logical and structured colleague passed the exam, I just logged into the AWS account and checked to see when I could schedule my exam too. Well, I’m not sure what I did, or maybe my Firefox trolled me, but aside from an exam date four days away, the next one was three weeks away. And being already panicked that I am not retaining information I feared forgetting anything in three weeks. So I scheduled my exam on the 25th of October, at the time I had no other choice. And I did this on Monday the 21st of October. I spent the next three days reading, writing, listening to those video tutorials again and panicking. In a way, whatever the result, at least I would be able to take a break from reading Amazon propaganda. Because this is 90% of the training material.:))

And luckily, I passed.

After that, I talked to my college and told him why I scheduled the exam so rashly and he showed me on his computer the calendar with available dates and well … there were a lot more dates available than what I saw.

So yeah, I scheduled myself by mistake, quite rashly for the AWS Cloud Practitioner’s exam. I was definitely not completely prepared for it. But apparently it was enough. And now I can take a break from reading about how to use AWS services and actually solve some useful tasks.

Lesson learned: Some mistakes are worth making.

All is well with the world.

Stay safe, stay happy!

Apr 07 2019

Is Spring still relevant?

Category: TechnicalIuliana @ 13:39

This Friday I’ve had a debate at the company with a colleague of mine which is known to be a straight up genius about the topic in the title. Obviously, I was arguing that Spring is still relevant, and my colleagues was arguing that it is not. How did I end up in this position? Well, since I’ve written so many books about Spring, why not? I’ve written books about how it can be used, explained its under-the-hood internals to others, I could talk to others about it, right? Well, turns out… not really. I am really bad at debates with geniuses, that happened to study computer science. Because I’m an engineer, I’m practical, I get down in the dirt to make sense of things and fix them up. I build things from scratch, and although I do overthink and design things, my overall direction is practicality. And this is what being relevant is for me. Can it make my work easier, faster, stable and can in the end produce revenue? Then it is relevant. So yeah, for me being needed and being useful means being relevant.

For him, being relevant, means change, means driving the domains toward innovation.

And because, our definition of relevant was different, the debate was a cluster-fuck. Funny as hell, but a cluster-fuck nonetheless.

Here is my take on this.

Continue reading “Is Spring still relevant?”

Tags: ,

Jan 04 2018

10 Commandments Of A Career

Category: TechnicalIuliana @ 23:18

I don’t know if 11 years of experience in programming and three published books can be considered a career, but in this 11 years I got promotions I did not chase or even wanted so this must count for something. I do not know if I did anything different than others that try to succeed, but my attitude and hard work got me from a low place to a place higher than I even dared to dream so I thought it might be useful for others.

So here there are, the 10 commandments of my career.

1. Do your best. Sounds easy, sounds simple, but it is difficult to do your best. Especially on your bad days. The truth is you will spend at least 8 hours at work, you might as well use it properly, to deliver quality products and acquire quality knowledge.

2. If you do not like it, change it. Nothing is perfect in this world, thus companies are not either. You will get defective management, defective products to work on, defective people to work with. But nothing changes its state without interference and stimuli. So do your part: speak up and act. You would be amazed how much much you can change. A strong warrior is forged in battle so be thankful for the battles you have to take part of.

3. Ask. Do not expect people to know or care, what you want or need. If you do not ask, people will rarely know what you need and give it to you. There are also people who are shy and can’t say no, even if they don’t really want to give you something. So ask and insist when necessary.

4. Read your contract, know your rights. This should be obvious, but many people skip this part. You have more rights than you think. There are rules put in place to protect you from bullies that are high up the corporate ladder, because with great power sometimes it’s not the great responsibility that comes, but great assholeness. So know them and invoke them when necessary.

5. Never stop improving. This should also be obvious, but some people get cozy at their jobs and get complacent. The only constant in this universe is change. So ride the change like a surfer rides the ocean. Keep your mind fresh and open and enjoy all the wonders of changing time. People who are reluctant to change fade into the background of the company, those who welcome it shine like the sun.

6. Speak up.Do not be afraid to voice your concerns and make proposals. Be open. Be creative. Even in companies that are known to have rigid hierarchy and fixed processes, exceptions can happen when good ideas are strongly voiced. Provide feedback whether is positive or negative. People like being complimented for their good work and even if uncomfortable, people accept that they have to improve. Those that do not want to improve, will most likely quit at some point anyway.

7. Establish boundaries. Be explicit about your do’s and dont’s. For example, it’s ok to state upfront that you do not like overtime, or working in shifts. Preferably do this at the interview, but if you were ok with this at first and then later some changes in your life  make you incompatible with this sort of activities, do not be afraid to communicate it. Contracts are not always explicit about your responsibilities and anything you are asked to do that is not in there, you can be negotiated upon.

8. Work with friends, not colleagues. We are humans, not robots. We make mistakes, we change, we have good days and we have bad days. Know your colleagues. The key to a productive team is to figure out when people are having a bad day and not pushing them and to figure out when they have good ones to challenge them. Also, building trust and friendship with your colleagues leads to a more comfortable working environment, that ultimately… does not feel like work. The truth is, for at least 8 hours a day we share the same space, breathe the same air with a select group of people. The key to a good collaboration is to know their strengths and weaknesses, and harness any of them to build a quality product.

9. Learn from the best. Learn from the worst. Learn from mistakes. And teach others. We are humans, we have genius epiphanies and brain farts. We have cheerful moments and we have low ones. Every experience is learning experience. From the best, copy behaviours that will make you the best. From the worst you can learn what not to do. From mistakes you can learn what was tried and failed, so you will know what not to try. And yeah, preferably learn form mistakes done by others. And teach others. We all die not knowing a lot of things. But be generous with your knowledge, share it so we all die knowing more things. ;)

10. Keep it simple. To make things complicated is easy. You don’t even have to try too much, just take something that you know and build it in your own personal way, thinking that you will never share it with anyone. To people that do not know what you tried to build and how, it will look complicated. The hard part in any domain is to build complex things in a simple way, so that others can understand it and contribute to it. So keep things simple. Implement complicated things in simple ways. Simple is the most practical way after all.

I know some ideas in the above paragraphs might related or even repeated. But, as Aristotle says: “We are what we repeatedly do; thus excellence is not an act, but a habit.”

Stay safe, stay happy!

Oct 15 2017

Spring Stereotype Annotations

Category: TechnicalIuliana @ 21:18

Having finished writing my third  Spring book, it was about time I should start writing technical posts as well. Being an accessible online person, quite a few people that read my books find mistakes or have interesting questions. I am really happy when people find mistakes, this means that they are actually reading the books, taking them seriously, including reading the references to the official documentation, which is more on point and more detailed than a book written by an “external” will ever be.

And I am happier when questions that question my own understanding of the framework are risen as well. Because this motivates me to dig deep into the documentation, to ask other technical people I know what their opinion is. It is an opportunity for communication and debate.

The last question I had from a reader was about the @Configuration annotation. He asked why is this annotation not mentioned as being a stereotype annotation in the book and if this is not a mistake on my part. He gave me some links to some official documentation and his opinion about the matter. After I queried  multiple resources, including my technical reviewer, who is a Spring  trainer for Pivotal this is the answer I came up with.
Continue reading “Spring Stereotype Annotations”

Tags: ,

Sep 08 2017

So I read the Google manifesto…

Category: TechnicalIuliana @ 12:12

Before going on vacation the Google scandal of the 10-page “Google’s Ideological Echo Chamber” document was just starting. A guy at Google created this document in which he criticised the politically correct Google environment and the discrimination happening in the name of the political correctness. And that manifesto made it to the internet. I was preparing for a vacation like no other, in which I was to detach myself completely from my working environment and from the passion that I dedicated myself to for the last 16 years of my life. So I postponed reading the Google manifesto until getting back.

I read the document on the plane on my way back and I realised there is a lot of blogging material in there. Because here we are in the time where political correctness dictates which people are allowed to speak their minds out loud and which are not, unless they want to risk being fired.
Continue reading “So I read the Google manifesto…”

Tags: , , ,

Sep 05 2017

I love writing technical books…

Category: TechnicalIuliana @ 23:23

… and messages like the ones below make all the effort worth it.

Tags: ,