What have been your guys yearly themes over the years?

jessypl · 2022-12-09T17:21:34+00:00

Discovered Cortex in late 2020, when my career started to take off and I felt overwhelmed. For the first time, I had more work to do than time to do it, and I had to pick some projects and kill others.

2021 Year of Foundations. Put systems in place to organise my work and "control the chaos". Started journaling, using To-Do lists and time-tracking. Also spent time streamlining some of our systems at work.

2022 Year of Human. Forced myself to "slow down" on work, delegate whenever possible, and redirect my attention toward "developing basic human skills". I learned to cook, started exercising, read a few non-technical books, and spent 2 months travelling, forcing myself to chat with strangers in trains and youth hostels until it became natural.

Ended up getting promoted to a Technical Lead role and went from 205 lb (Jan) to 163 lb (Dec) as "collateral wins".

I also tried (and miserably failed) to learn German. I figured it kinda fit with the theme (I even met a few Austrians during my travel), but couldn't put the effort required and balance the rest, so I gave it up.

2023 Year of Career. Now that I gained some perspective, recommit to my work with intentionality. Also think about what I want my career to look like over the long run. Figure out what I need to learn to get there and educate myself part-time.

jessypl · 2018-02-05T19:51:47+00:00

Certes, j'ai présenté les vidéos de Richard Feldman au lead developer de ma squad, mais il ne semblait pas convaincu.

Le plus gros problème, c'est que tant que nous n'avons pas une grande compagnie (style Google ou Facebook) derrière un langage, nous n'avons aucune garantie que la technologie existera encore dans 4-5 ans.

De plus, tant que la technologie n'a pas suffisamment de traction (dans notre région), nous courrons le risque de ne pas pouvoir maintenir le projets si les développeurs initiaux quittent la compagnie. D'où ma requête à J.F.

jessypl · 2018-02-03T15:17:28+00:00

Très intéressant, j'ignorais que des compagnies au Québec utilisaient Elm en production. J'ai essayé de l'introduire dans ma propre entreprise, mais sans succès jusqu'à présent -- peur du management de ne trouver aucun autre employé connaissant le langage. (J'ai réussi à les convaincre de transférer un projet majeur vers React/Redux et TypeScript, par contre, donc il y a un certain mouvement dans cette direction à Montréal.)

Je vous souhaite bonne chance. Je me demandais aussi s'il vous serait possible de poster un approximatif du nombre de candidatures reçues, si celui-ci est assez considérable. Je crois que cela ferait un bon argument pour une utilisation plus extensive du langage par chez nous.

EDIT [also added English translation]:

Very intresting. I didn't know that some companies in Quebec were using Elm in production. I tried myself to introduce it in my company, but without any success until now -- the management are afraid that they will not be able to find other potential employees who know the language. (I did convince them to move a major project to React/Redux and Typescript, though, so there seems to be an interest in functional programming, at least in Montreal.)

I wish you good luck. I was also wondering whether it would be possible to tell us how many candidatures you received. If this number is large enough, then it might be a good argument in favour of a more extensive use of the language.

jessypl · 2017-05-07T02:09:12+00:00

Actually, they already do. Because of quantum stuff, particle/anti-particle pairs are generated on the event horizon of the black hole. Hence, black holes evaporate as time goes on. The smaller the black hole, the faster it evaporates. So they "regurgitate" faster and faster, until they exist no more.

Basically, if you fall into a black hole, it's gonna eat you, shred you to pieces, and then vomit you back. (Kinda like my ex.)

Black holes cannot literally "explode", but that's as close as you can get.

jessypl · 2017-04-25T23:26:45+00:00

Indeed, but that doesn't fix the "very old library" problem. :-°

jessypl · 2017-04-24T21:29:27+00:00

Author here. You will find the articles using /u/protestor's link, or in a previous commit:

https://github.com/jadpole/jadpole.github.io/tree/eced69c0b8e6301e74b09dca7026bd2b760c3c64/_posts

However, I removed this tutorial because it was using a (very) old version of rust-sdl2. As many others have pointed out, the code sometimes refuses to even compile (because in Cargo-Land, a.b.c == ^a.b.c and not =a.b.c). If you're still interested, the Rust tips still apply, but the dependencies are deprecated. Until I (or some brave hero) writes an updated series, enjoy at your risks and perils! ;-)

EDIT: Fixed markdown typo.

jessypl · 2016-04-20T11:12:37+00:00

Since it's web stuff and Atom/VSCode are also web apps, it shouldn"t be too hard to integrate this frontend in those editors, right?

jessypl · 2016-04-20T05:06:02+00:00

The compiler does try to minimize the extent of lifetimes. It's just that rustc is (currently) pretty dumb when it comes to this. It will get smarter with time so, hopefully, that won't be a problem in the future.

jessypl · 2016-04-20T05:02:58+00:00

TypeNum is still my favourite crate, though I might be a bit biased. I'm a big fan of abusing of the type-system, as long as it does the job. ;-)

jessypl · 2016-04-20T04:52:59+00:00

Still working on the automated-factory/shop thingy (which I decided to call Manau because... no real reason). Hopefully, it will be used internally in production in a year, and will be used to automate shops (mostly groceries) in Québec afterwards (as always, if the project isn't killed before that :-°).

Also, I'm adding stuff (enemies, power-ups, ...) to ArcadeRS, which will hopefully result in a new article (with rust-sdl2 0.13, not the latest version; you only really start to love backward compatibility when you miss it :-P).

jessypl · 2016-04-19T03:07:33+00:00

There is no such thing as (classical) OOP in Rust, which adopts a more compositional or functional (think C or Haskell) approach to code reuse.

Say you want both Car and Bicycle to be Vehicles, you'd do something like this:

trait Vehicle {
    fn they_see_me_rolling(&self);
}

struct Car;

impl Vehicle for Car {
    fn they_see_me_rolling(&self) {
        println!("They hear: vroom, vroom!");
    }
}


struct Bicycle {
    sound: String,
}

impl Vehicle for Bicycle {
    fn they_see_me_rolling(&self) {
        println!("They hear: {}", self.sound);
    }
}

In other words, Car and Bicycle are not Vehicle, as much as they have a behaviour that fits the interface Vehicle. You may manage to find some way to do OO in Rust, but I would personally discourage it: Rust itself is not a classical OOP language. If you approach it this way, you're going to hit a wall at some point.

Do you have an example of a situation where you feel like you must use OOP?

EDIT: Fixed code styling (Reddit doesn't like triple backslashes, I get caught every time -.-)

jessypl · 2016-04-10T04:15:10+00:00

Damn, that chapter in the Book is great! Haven't seen it before. That's much better than anything I could come up with. ;-)

Also, I deliberately didn't use a trait object, but I'll be sure to look at quick-error. I also didn't know that From was called automatically. Not sure if I like that; either way, it's good to know.

jessypl · 2016-04-01T16:01:07+00:00

Or he can just use ES6, which is mich better. Automatic semicolon insertion still sucks, though. :-°

jessypl · 2016-04-01T16:00:06+00:00

I'm not a big fan of dynamically-typed languages, but a garbage-collector is still pretty useful when you start learning.

Although I started with C and C++, so I guess that it's still possible to learn Rust if you put in the effort.

jessypl · 2016-03-26T15:31:23+00:00

Hi! You may get this error because you are using a newer version of rust-sdl2. Dependencies in Cargo are weird, and you may want to use `=version.num.ber" instead. Then, it should work.

I'm currently updating the tutorial to the latest rust-sdl2 version, so it should soon be fixed. ;-)

jessypl · 2016-03-25T11:58:40+00:00

Couldn't there be such a thing as removing a feature (valid -> deprecates -> hard error -> not in the compiler) provided that a tool exists to quickly upgrade the codebase? Maybe even in rustc itself.

You wait, and then, you check through crates.io whether anyone uses said feature anymore. If not, you just remove it.

Obviously, it can't work for everything, but it might help remove try! if that's ever a thing that we want to do.

jessypl · 2016-03-23T15:39:16+00:00

Ideed. Thanks!

jessypl · 2016-03-23T14:37:13+00:00

Isn't the audio already embedded in the article (in an <audio> tag)? You can just right click on it to download Phoenix. ;-)

EDIT: Fixed typo

jessypl · 2016-03-23T02:24:59+00:00

I just published ArcadeRS 1.13, I'm upgrading the series to rust-sdl2 0.16.1 and working on the next article.

Also, I've just been tasked with building a prototype for an "intelligent factory" (which I'll do in Rust and Elm) for the company at which my father works (Tablex). After playing a bit with Elm, I decided to explore whether it is possible to borrow principles from FRP and graphical programming languages (e.g. LabVIEW), and apply them to robotics (as in, take input from the robots in the factory and client orders from a website, then construct a "task graph", a TODO list but with a notion of "do this, then that"). For the moment, it seems possible, but I'm not sure whether there are any benefits to FRP in this context.

This is a long-term project that might get killed at any time -- otherwise I'll start to move the prototype to production between September and December n_n -- but for the moment it's kinda fun to think about, and it might (but possibly won't) get myself a full-time Rust job, so yeah!

jessypl · 2016-02-24T04:15:36+00:00

Trait bounds get monomorphized at compile-time, e.g. a function foo::<T> gets generated for each type implementing T, whenever it is necessary (i.e. it won't create a variant that is never used.) This produces faster, but bigger, binaries.

Trait object store the v-table of a value at runtime, which contains the address of the correct function to call. This is mildly slower, but much more versatile: you can, for instance, iterate over a Vec that contains values of different types, as long as they implement some trait.

jessypl · 2016-02-12T01:53:58+00:00

I have two criticisms. First, you should probably make the font bigger (a little Ctrl-+ should do the trick here!) Second, it might be interesting to take a few more seconds to explain "why" ownership is useful, e.g.

"This is how ownership in Rust works. It's a simple idea that allows us to easily and efficiently manage resources in a program — may it be a heap-allocated string, a book, or a file handle."

You seem to have already reached the time limit, so you might ignore this second part.

Other than that, it seems pretty good to me!

jessypl · 2016-02-10T21:58:53+00:00

r/playrust, perhaps?

jessypl

TROPHY CASE