That’s not really a big news as the feature is in development since some times, but you may have heard about “Twitter Notes”. To summarize, this feature will allow its users to write actual blog posts without the well-known 280 characters limitation. I’ve never liked Twitter, and generally the social medias based on the audience, magical algorithms, and immediate reaction generating shitstorms, and also selling their users like a vulgar bag of meat. And I’m not a subscriber of this platform.

But, I think it’s a good thing.

I’m not a social media user since a lot of time. The first I’ve subscribed is Fosstodon because I was mainly curious about the Federate social platform and finally I’ve found a good place to communicate. Before that, I was just blogging on Plume, which is also federated.

In my opinion, the major difference between micro-blogging and classical blogging is the characters limitation (Thank you Captain Obvious) and also the flow speed. In my experience with both blogging and Mastodon-based social media, on the second one we aspire to a more immediate posting and sharing than in traditional blogging. Something liked, disliked, a though we want to share, a lot of reactions posted on micro-blogging platforms is immediate and the immediate answers or notifications amplify this effect (our brain is addicted to dopamine, that’s logical).

On an ordinary blog, being disconnected from the continuous flow permit to take your time to write your words. You write your post when you want, at the speed you want, offline or online, and you send it. Still on my experience here, it can take me days, or weeks, to write a single blog post. Because of various reasons : time, mood, ideas, related to an activity that takes some time, etc. Or I can also write and develop an idea and publish it in the hour.

On a micro-blogging platform, I don’t have the feeling you can do this and the Threads view can become quickly unreadable. When a message included in a thread is retwitted or boosted, there is a lot of risk to lose the initial context and being confused by it. A blog post is an autonomous text, consistent and complete, that can never lose its context (unless it’s poorly written, this can happen too…). Fosstodon’s admin Kev Quirk wrote about this on his blog and I share his opinion, I invite you to take of look on it.

Because of social medias encouraging to react immediately, and because you are encouraged by the number of “followers” or “retweets/boosts” to continue, I think you can’t have the time to properly put your though into words. The reaction is more immediate, more crude, and that’s the basis of the daily Twitter shitstorms we heard about on the news. Because you can’t develop a solid opinion with a 280 characters limitation. Even with Mastodon’s 500 characters I think its still difficult and you have to shorten your though. I usually take my time to write my messages on Fosstodon (and I don’t publish a lot to be honest), answer to people and share some opinion with them. Of course, one of the main reason is because I’m not an English native and I’m always afraid to write something that could be wrongly interpreted because of a mistake.

But also because I usually try to avoid immediate replies.

You may have lived this kind of situation at your work : somebody sends you an email, then sends you a chat to ask you if you’ve read their email (or call you on phone…) ? It’s like we can’t now wait for a reply, everything must be immediate and if you take your time to read the email and reply it, the sender will think you’re not working because they didn’t had the response in the minute. That’s the best way to make a situation going uncontrollable and escalate in verbal violence. In my experience, these kind of situation happened more often since the COVID pandemic and the generalization of home working in France. If you didn’t answer to a chat notification or an email in the minute, the sender will think you are sleeping in front of Netflix, inducting the feeling to yourself that you have to answer quickly. A hellish loop. For me, the continuous flow of the social medias is the same thing.

I think I’ve exposed my opinion about hte differences between a traditional blog and the micro-blogging, so, let’s go back to the original topic : about Twitter’s Notes feature. Like I’ve said above, I think it’s a good thing that Twitter finally understood you can’t develop an idea with 140, then 280, characters and permit its users to develop them with a more confortable medium. When the social medias and the micro-blogging took the majority of the users and the Forums and Blogs get deserted, I’ve though we’ve lost something. Of course, they still exists, and for a professional usage it’s always cool to find a good blog explaining things, but some disappeared. I remember some French bloggers that produced nice content deserting it in profit of social medias because it was easier for them and the centralization was an apparent good way to reach their followers (spoiler alert : nope). That’s why I’m still thankful to directories like Yer Old Blogroll where you can still find some nice content writers.

However, I’m wondering if it’s not too late for Twitter to implement this feature ? Nowadays, I have the feeling that reading a more than two lines length message on a forum or a social media became the most difficult exercice in the reader’s life. And with the video getting a major information vector, I’m wondering if Twitter’s users will be receptive to this feature. I can’t stand being always redirected to a 20 minutes video (containing 10 minutes of useless filling and product placement) when a text article can do the same in a more efficient way. But maybe that’s because I’m a grumpy old guy.

Having finished Heavensward, let’s chain with Stormblood New Game+ mode.

Stormblood starts right after the fall of the Baelsar’s Wall conducted at the end of the Heavensward main story line. As the Eorzean Alliance does not wish to engage a frontal a war against the Empire, they send the Scions and the Warrior of Light, who are neutral, to contact the various Ala Mhigan resistance factions behind the newly opened border. Meanwhile, the Domanians Tsugiri and Gosetsu left the Scions and set back to their homeland in order to fight their mutual enemy.

Like Heavensward, Stormblood is split in four main parts and follow exactly the same pattern. The two first parts are the initial story released when the expansion came out and the last two are additional content added until the release of Shadowbringers. Also, just like its predecessor, Stormblood use the same starting narrative pattern for its introduction by following two Resistance representative in the two first explorable regions and then, converging to the next chapters. The two-step exploration of the regions introduced with the Sea of Clouds in Heavensward is more used in this add-on with three of the six new area added using this idea (The Fringes, The Peaks, and Yanxia). Finally, just like Heavensward, one of the leveling dungeons is not a story mandatory. In this case, that’s the second one.

However, Stormblood broke an implicit rule in the exploration established during the previous stories, and the next ones : the secondary city is explored first. In FFXIV, each story line has at least one main Capital and a secondary which is generally the endgame hub (because it hosts the various merchant selling high level gears, the craft and harvesting jobs collectable appraiser, etc). In ARR, we had the three City States that were the starting zones, and the Revenant Toll where the Scions installed themselves during the story and hosting the ARR endgame hub. In Heavensward, the main city was Ishgard and the secondary hub Idyllshire. In Stormblood, we discover and explore first Rhalgr’s Reach, one of the Resistance factions camp and the endgame hub before discovering Kugane, the Othardian capital. As today, Stormblood is the only one who had broke this rule, Shadowbringers and Endwalker having not.

Regarding the cities, there is a common pattern I haven’t explained in my two previous articles. Every time the player discovers a new major city, he will have a tour offered by a NPC character related to this one. At the very beginning of the game, the adventurer discovers its starting city by doing some exposition quests. This pattern was used again in Heavensward when the Fortemps’ butler introduce the various areas of the main capital. Then, in Stormblood, it’s the local NPC host who does this tour again. Of course, this method was used again in Shadowbringers and Endwalker.

Another common pattern since the beginning of ARR is the Headquarter place. At first, when your character is recruited by the Scions, he will meet the other members and the leader in their headquarter in Thanalan, then at the Revenant’s Toll after moving during the first story. During Heavensward the HQ is the Fortemps Manor where the team plans its operations. In Stormblood, it’s the Ruby Bazaar where the characters are welcomed at the beginning of their adventure in the Far East, and later the Doman Enclave. The HQ is an instanced area where the NPC disposition varies according to the story development and several cutscenes are played.

The first part of the story is narrated by Lyse, the member of the Scions we knew under the name Yda who hide her identity by taking her late sister’s in order to fight among the Resistance. The first Stormblood region to be discovered is Gyr Abania with The Fringes and the Peaks and the second city as told before. The beginning of the story returns to a more classical approach of the “I don’t trust you, go kill 3 rats” pattern. Not exactly that, but we arrive in a region controlled by the tyrannic Empire and the Resistance suffered a lot of loss and is now mistrusted by the various villagers because their actions trigger the Empire’s retaliation, which fall over them. During the first chapters, we try to help the Resistance to recruit new members, but after a violent assault over the Resistance HQ by the Empire, the second main chapter begins with the travel to the Far East. There, the story pattern is the same as the beginning, our characters are completely unknown in this region and they want to find the Doma Rebellion Front in order to rally them to fight the Empire together. Because Othard’s people suffered of twenty-years of occupation of the Empire, the recruitment is difficult here too. Despite using the same narration mechanics as the beginning of the game, the first part is using them differently. Instead of being sent to do some house chores, the trust in our character is earned by helping the local people to pull back the Empire occupation forces. The first part end after fighting a second time against the story main antagonist, Zenos. This is also in this chapter where we unlock two new features of the game, the submarine exploration and the aim system where the character has to aim and shoot at a remote target using a magnifier. Another feature added in this expansion, but lately after its release, is the “role play” system. During some specific story parts, we play as another character a specific duty instead our character.

The second part starts by searching the Doma throne heir, Hien in another region and firing up the revolution in Doma. The first chapters were mainly building the new characters back story and starting to develop the background of one of the two secondary antagonists, Yotsuyu, the cruel acting viceroy in charge of Doma. We also discover another tribal population of Doma in the Azim Steppes, a variety of nomadic tribes composed of fierce warriors. Then, the music accelerates and the story continue directly with the liberation of Doma and the begin of the demise of the Empire in the Far East. After this victory, our team returns to the Ala Mhigan region to continue their purpose and free the region from the Imperial domination. These two parallel stories has a common element : the secondary antagonist is a native of the conquered country who fight their kind and are considered as traitors by the resistance and other citizens. In Doma, Yotsuyu is the acting viceroy put in charge after Zenos left the country. In Gyr Abania it’s Fordola, the daughter of Imperial collaborators who gained citizenship, known as “the Butcher” and leading a team of native soldiers named the Skulls. Both of them are cruel and mean, and both of them had been put in place by Zenos who saw their hateful potential as an opportunity. The second parts ends with the defeat of Zenos at Ala Mhigo and the liberation of the city. Then, just like Doma which was under Imperial rule for decades, the country has to rebuild itself nearly from scratch.

The third part starts is a different way, as the two liberated countries are now rebuilding themselves. The Adventurer is approached by another NPC for a treasure hunting venture, a fabled treasure that has been hidden by the last Ala Mhigan king, the “mad king”, hoping this fortune could help rebuilding the country. And that’s fun, because this is exactly how the third part of Endwalker started to years after ! After this introduction, the story continue and reveal the difficulties of the new temporary rulers of Ala Mhigo, as the people asks for revenge against the imprisoned traitors like Fordola. The third part is interesting because it’s main purpose is to develop the two secondary antagonists following the fall of Zenos. Both of them are still alive but one is missing and presumed dead, and the other is imprisoned because the characters didn’t want to arbitrary execute her. We already knew in the second part that Yotsuyu and Fordola had reasons for hating their own kind and being what they became for the Empire. The third part also introduce a new minor antagonist from the Empire, Asahi sas Brutus, another Domanian who took allegiance to the Empire and is Yotsuyu’s step brother. From my perspective, this characters is the most poorly written of the whole game. His treachery in the story could have been better introduced as the beginning of its appearance left some doubts about his motives, but the story preferred to develop this one has a stupid and caricatural character leaving him into some delirious hateful revenge quest. It’s sad to see the Yotsuyu development story line spoiled by this useless character. By the way, if I remembered hating Asahi at the first story run, I was also remembering not liking Yotsuyu’s character. She was just hateful and megalomaniac, too much caricatural too. However, reading again the story show how much it’s a tragic character. That’s one of the good parts of Stormblood’s story : the two secondary antagonists has both the same back story basis, being child of Empire collaborators in an occupied territory, but a different development showing different possibilities for this kind of character. Fordola was the beloved daughter of a minor noble who gained Empire’s citizenship who lost her father because of a riot, while Yotsuyu has been an orphan child mistreated and abused by her adoptive family, later sold to a sordid establishment. Both of them grew hatred for their kind, but not for the same reason. And both of them gained the interest of Zenos, the principal antagonist of this story line.

The fourth part is the transition for Shadowbringers’s story line. It starts by Doma securing its defenses again the potential Empire counterattack. Also, the word of Zenos’ survival is spreading and one of the Scions decide to visit the Empire as a Doman emissary. However, while preparing their next moves, the Scions are suddenly targeted by a strange affliction that made them falling into a deep slumber one by one, leaving the Warrior of Light soon very alone. This narration part is very oriented to the development of the Empire background. Despite being one of the two main antagonists of the story, the Empire remained quite mysterious and its internal affairs were barely exposed to the player. In Stormblood, the Empire is clearly most developed than in the previous campaigns. While I’ve though at first that Stormblood didn’t add a lot of introduction to Endwalker like Heavensward did for Shadowbringers, actually it’s more subtle. Instead of introducing a part of the next expansion story line, this one set the stage for a specific event that will happen in Endwalker. So, the narration will take a lot of time to clarify some back stories and origins making the plot of Shadowbringers and later Endwalker more consistent. Also, some future characters of Endwalker are introduced during the last parts of Stormblood. The “Role play” feature is reused a couple of time and I’ve really enjoyed these gameplay sequences. They provide another dimension to the story where your character becomes a third party event and the player is now focusing on another parallel action. Despite drawing a lot of backstories, the fourth part is apparently shorter than the third. Its story is quickly completed and we can see it’s mostly a conclusion to Stormblood’s story and the startup of Shadowbringers.

One last thing about the two last parts of Stormblood : they don’t have any narrator, unlike the previous chapters. Maybe because the story is developed in a two concurrents branches later merged so it could be difficult to have a specific character narrating it.

This review of Stormblood’s New Game + is quite longer than the previous. To be honest, this rediscovery was actually more a discover than a second reading. Back at this time, I’ve stopped playing FFXIV because I was a little tired by Heavensward and I wasn’t enjoying the game as much I enjoy it now because some gameplay features later implemented were a real benefit. So as I had preordered Shadowbringers, I can admit I’ve a little rushed Stormblood and I can’t say I was receptive to the story. Maybe the Japanese theme of the game didn’t match my mood of the moment. I remember better the last part and now I can say I’ve enjoyed the story of this add-on. Stay tuned for the next part of this New Game + series that will talk about Shadowbringers.

Some months ago, I’ve made a series of articles about the misbrands, a collection of brands logos derivations that put a name onto the logo of a competitor product. They were really fun for me and I’ve put some on my work laptop. Curiously, it took some times to have somebody noticing the wrongness of these pictures.

Ubuntu with Debian logo - license CC-0

Some purists didn’t like these images, but it was for me a nice opportunity to explain one of my work principles. I’m working as an IT architect in CICD patterns and DevOps culture. Our goal is to provide a software delivery methodology, standardize it as much as possible for reusing, and also unifying the tools used in this context. At the beginning of one of my missions, there were various directions in the IT department that were working with CICD patterns. Some were actually developing specific software, and other were integrating and using the continuous delivery and deployment patterns to package and ship into the Information System softwares originating from the market.

Because of a lack of direction in these practices, almost every team had their own CICD platform, work usage, and tools. Some of them were nicely organized and others were really amateur because of a lack of knowledge or investment.

So, our mission was to collect the various uses cases and construct a delivery model that could be applied to the whole company instead of everyone living their life in their corner of the information system. Of course, we choose a tool chain according to the uses cases and if some teams were already using they tools, other not. And I’m sure you know what’s happening when you ask for someone to change their habits… They panic, pull the emergency brakes, and cry because they don’t understand why you want to remove them their toys.

Crying baby, opencliparts, Public Domain

By the way, during project construction, we had some people asking if we had already choose the tools while we were still collecting the use cases. When you focus too much on the tool you forgot the essential : what do you want to do ?

• We’ve made our choice, it’ll be a bike !
• Nice, we need to cross the Atlantic Ocean

¯\_(ツ)_/¯

Then, after the use cases were collected and the choice made, we’ve explained something to the concerned teams : your tools are disposable, the most important thing is how do you work.

Let’s use a stupid example : a hammer is a tool. Whoever the manufacturer is, its purpose will remain the same : planting nails. The IT tools are the same thing. Of course, more complex and some have their custom ways, but basically : GitHub, GitLab, BitBucket, Gitea are all Git-based source code repositories. So you should not force yourself to stay on it because “we’re used to it” even if it’s a bad choice (common example : a poorly maintained self-hosted GitLab installed one day that became an important tool, but a security concern and a chore, or a risk when it crashes).

Rares were the teams who had written their work methods, their habits, practices, and methodologies. The documentation was minimalistic and mainly tool oriented. Basically, they documented how to use the tools, and not their work.

When you buy a furniture at Ikea, do you want the instructions to tell you how to assemble it, or how to use the screwdriver ?

The branching method, the merge strategy, the code review process, the delivery process, all of this was documented (when it actually was) according to the tool and not according to how they manage these parts. The real methodology knowledge was mostly orally shared and not written.

So, instead of hearing them saying “we use GitLab for…”, “we use SonarQube for…”, “we use Nexus for…”, we asked them :

• How do you implement a new feature to your code ?
• How do you implement a fix to a production code ?
• How do you test your code ?
• How do you store and install your artifacts ?
• How do you deploy your application ?
• …

The purpose of these questions were to help the teams to write their methodology and let it live and evolve. You use Jenkins to manage your CICD pipeline ? Explain what they do ! Despite the differences between Jenkins, GitLab CI or GitHub Actions, they’re basically doing the same things : scheduling and chaining tasks according to events. Same for an artifact repository : their purpose is the same, so you don’t have to explain how do you use Nexus or Artifactory but how do you manage your artifacts.

Of course, it’s still important to document how do you use your tools. But, if you have documented first how do you work, a lot of tool-oriented documentation can become useless. Typically, if you document the definition of done in your methodology : at what moment can we consider the developer has finished their job and can ask to merge the produced code ? What is expected in a code review ?

I’ve seen documentations saying : “you connect on GitHub, open a pull request for your branch, and assign the team for the review” with screenshots and on. OK nice, but GitHub has already documented this, so why rewriting their doc ? Something more interesting for me would be, for example, a simple checklist of what the developer should do while opening the pull request :

• I’ve made a self review
• I’ve tested my feature on the dev server
• I’ve updated the documentation
• etc

That may sound obvious for a lot of people, but the obvious things are sometimes the most forgotten ones.

Another reason why I think a well documented methodology is more important than the tools is to help a new teammate integration. I’ve often seen the integration of a teammate to be just reproducing what their mentor does. I was sometimes wondering if the new guy did really understood what he was doing. When your work habits are correctly written, you also understand how do you work. A side effect of a well-documented work method while enrolling a new teammate is also to have some feedback on it. Which put me to another interesting purpose of a good methodology documentation : to challenge it, take some step back and ask some questions. “Why are we doing like this ?”, “Wouldn’t be better to try this ?”, etc. Also, a reference documentation is important to ensure everyone in the team is working in the same way. I’ve seen countless examples of undocumented work methods conducting to have everyone doing their way. And in these case, you say hello to the merge conflicts, disappearing features, introduced regression, etc.

So, to conclude, my opinion is that the tools are disposable, the methodology remains. Especially in the IT solutions and the DevOps culture where the tool chain is evolving at the same speed as the patterns do. The developers and operational need to adapt regularly and embrace new tools and apprehend new usages. But basically, the job is still the same … So instead of trying various tools and try to figure out how to use them, ask yourself first what do you want and how to do it. Then, the choice of the tool will be a simple formality and you will avoid to lock yourself in the wrong one.