Kartones Blog

Master English: 100 Phrasal verbs for IELTS, TOEFL, CAE, FCE is, apart from a very SEO-oriented title, another 4 hours Udemy English course that I took to focus on practising phrasal verbs. Using 10 topics and a conversation for each, you'll do some exercises and learn multiple examples of usage of each of the hundred verbs.

Correctly done and pronounced and easy to follow, although in the conversations the speed is noticeably fast (so if you already listen it at 1.25x or 1.5x they speak really quickly), while I think I didn't learn anything new (I've completed more courses about phrasal verbs), it was a good practice and reminder exercise.

Posted on 2020-01-20

Business English Course for ESL Students is one of those focused courses you might want to take if you need domain-specific vocabulary training. Mostly containing work-related words, sentences, phrasal verbs and idioms, it's near 6 hours of videos are quite interesting, well done and practical.

Finance, retail, marketing, interviews, phone calls, meetings, being polite/correct at work (with your colleagues, etc.), even topics about computers and entrepreneurship and stock market, everything is exactly what you would expect. If I had to find something to improve, maybe the medical field chapter is too specific, but for your everyday life is still useful, so not a real complaint.

Posted on 2019-12-27

Review

Title: Stay Awhile and Listen: Book II: Heaven, Hell, and Secret Cow Levels

Author: David L. Craddock

Four years later than the first book, we return see how Blizzard North (ex-Condor) deals with the massive success of their action RPG, Diablo. From the outsourced Diablo: Hellfire expansion (a decision they wouldn't make again), to the full development of Diablo II and its expansion, Diablo II: Lord of Destruction (this time, fully built in-house), and the initial development of both Diablo III and a new space-themed action RPG (nicknamed "Starblo").

Where in the first book we read a story about titanic efforts and unstoppable desire to create a great game, of how a small company was able to revolutionize the computer RPGs genre with tons of hard work, this second tale as a grim overall tone. Yes, Diablo II was a success (I've poured way too many hours on it and was one of the first games I played in multiplayer) and technically was impressive, but reading this book one feels sad of how some bad management and egos (and maybe other factors) destroyed a promising company.

I haven't exactly measured it, but probably half of the contents relate with negative concepts: fights between Blizzard North and Blizzard Entertainment, fights between the office's own employees and bosses, fights with the external company that created D1's Hellfire expansion, fights with Blizzard's parent companies... Here most of the struggles are human, social, instead of technical; there are technical problems to solve, of course, but don't feel as impacting as in the first game.

The insanely long crunch periods, the (not very healthy) rivalry between both Blizzard studios, the backstabbing of employees as years passed by, and the sad closing of the North studio after the bosses played a bluff and lost to Vivendi, leaving the company and opening the doors for a restructuring and posterior merge of some of the employees... All sums up to a great loss of the magic formula that created both games. The legacy lives on, and even in the recent early trailers of Diablo IV we can see ideas and characters meant for the third title, but it's not the same team.

I like that the book tries to give as many points of view as possible about many of the topics. For example, when it is talking about how the studio almost halted production for months after Diablo II shipped, you get to read points of view of the three bosses, old employees, new employees, people working on Diablo 2 expansion, people starting to work on concept art or the main story for the third part... even sometimes some opinions from Blizzard Entertainment employees.

It is a very interesting read, full of details and insider info that any fan of the franchise will surely love to learn. It will be interesting to read in a few years the third and last part, fully focused on Diablo III after being its development was restarted by Blizzard Entertainment.

Posted on 2019-12-21

Today December 2nd, 2019, marks a special date: exactly 15 years ago, I decided to start a blog to dump my development learnings and dull rants from time to time. The first blog post was about a game development framework I was using back then to prepare my master thesis project, Jamagic.

That original blog post now lives here, but I began using Google's Blogger as the platform to host my content.

I had another website with kind of posts (mostly tech-oriented news), but it was in Spanish and I wanted both to practice writing in English and to be able to speak about any topic I wanted.

For the record, I'll list the different platforms and approximate dates because one one hand it's been quite a challenge to migrate the data from one place to another, but on the other hand I've learned a lot about becoming more pragmatic and adopting leaner and simpler platforms, data formats and general approaches.

• 2004: Blogger. Simple design, could just add some simple Javascript for visits counting and showcasing (the only "analytics" you wanted back then).
• 2005: Custom .NET-powered blog platform (maybe DasBlog?). A friend created a blog community and invited me to move my blog there. I had to manually export and re-create the posts 😭.
• 2007: Community Server. Decided to try building my own blog community for me and my friends (although a few external people joined), so once again I manually exported one by one and re-inserted all blog posts.
• 2014: BlogEngine.NET. Software rots, and when you're using an outdated version of a closed-source application, even when it is extensive and I could also use .NET Reflector to learn about the internals and keep improving and advancing things, there comes a time to shake things up. Not without pain I migrated to a multiple single-instances setup of BlogEngine, which used BlogML and back then was a Community Server -> BlogEngine script. It was an important milestone in simplifying things not only because of a more open data format, but also because I could switch from having to JOIN half a dozen SQL DB tables to just maintaining a physical file per post or page.
• 2016: Pelican. I stopped working professionally with .NET in 2009, but kept using it for personal projects. In 2016 the only think I ever wrote some C# or ASP.NET for was for the blog, so to simplify my life I decided to jump the "static site generators" wagon and migrate once again the blog. This time was dead easy with just a simple tweaks, and Markdown allows HTML so all old posts were just dumped as such (I'd rather write new ones in MD). Compilation added an extra step but with some simple scripts I now instead do a "build and deploy" rather than a "edit and upload".

Quite a journey to fight to keep my content always available. Call me crazy but I hate when you try to search for something old and there are no search results. Google tends to de-rank and hide old stuff, DuckDuckGo started crawling the web later so doesn't knows everything and most often, companies, platforms and domains just disappear, so to me it pays off to keep your stuff somewhere you can ensure is available.

Maintaining the blog has also served the nice purpose of having a playground or sandbox where to test and experiment with many web-related topics. From building custom plugins and extensions to the platform it was running on, to removing all kinds of tracking and almost all javascript of the page, to maintaining as a personal challenge trying to keep things fast, overall is fun and refreshing to have some personal projects. And heck, I also feel I'm up to date enough in web topics to achieve things like:

Specially considering I mostly only do backend development nowadays.

To wrap up and stop wasting more time of any poor reader who made it until here, I'd like to be sincere: What I write here is usually and mostly irrelevant. I also lately feel less inclined to blog because I both feel I'm not going to add anything worthy and that the web is nowadays full of too many experts with shallow blog posts, posts that we then tend to take as the real truth. I feel I should instead be focusing on reading more books than contributing to this quick doses of "information", so my real message of this post is more like... don't waste much time reading only blog posts, instead to dig deep into a topic research books and papers, and experiment.

Talk less, do more.

Posted on 2019-12-02

One of my pet projects, Finished Games, is reaching a state in which already serves decently as a catalog and tracker. Sure I have a ton of ideas to add, more sources to get games from and many improvements, but the base system is working so I can start to tackle other areas, like automations.

I can manually add games to the database. I can import them from "catalog sources", and if already exists match them with the existing title, update certain fields, etc. But I still need to manually mark those games I own, so if, as in this example, a platform like Steam can provide me with a list of which titles I've got, and maybe which ones I've completed (by checking certain achievements), it's way easier and nicer.

So, without further ado, here's a brief introduction of the Steam Web API endpoints I'm going to use soon to be able to sync user catalogs.

Setup and Documentation

You can register for an API at https://steamcommunity.com/dev, and it is instantaneous, no need to wait for a manual approval.

Once you have an API key, the official docs are at https://developer.valvesoftware.com/wiki/Steam_Web_API.

Basic endpoints

I just need three endpoints to grab user data relevant to my use case.

Obtaining the steamid from a vanityurl (an account friendly name), like "kartones". Not everybody has them setup but I for example do, so better be prepared:

http://api.steampowered.com/ISteamUser/ResolveVanityURL/v0001/?key=YOUR-API-KEY&vanityurl=VANITY-URL

Fetching the list of owned games of a given user. Including game name, which saves you an additional call to fetch game details (which also returns no name for some titles! 😵):

http://api.steampowered.com/IPlayerService/GetOwnedGames/v0001/?key=YOUR-API-KEY&steamid=76561197987342492&format=json&include_appinfo=true

Retrieving achievements by game and user. Not only the unlock status but also the epoch timestamp of when it was unlocked (useful for deltas):

http://api.steampowered.com/ISteamUserStats/GetPlayerAchievements/v0001/?appid=271590&key=YOUR-API-KEY&steamid=76561197987342492

Additional Endpoint

If you want way more info about a game, from the description, release date or the developer name, to screenshots, platforms (Windows, Linux, Mac), genres and more, there is an store endpoint that works without authentication:

http://store.steampowered.com/api/appdetails/?appids=271590

Rate Limits

api.steampowered.com calls are rate-limited to 100k per day according to the API terms of use.

store.steampowered.com is rate-limited against abuse. I read somewhere that seems to be around 200 requests in a 5 minutes window, so you should cache those call results.

Posted on 2019-12-01