Archive for April, 2020

Video Stream – RPG Systems with Loot Generation

I asked on LinkedIn about whether or not people would be interested in a video stream that focused on programming, and I had some positive feedback. In order to test the waters, I decided I’d start with some system-design stuff given that I’m going through a bunch of practice with distributed systems. This is a bit of a change up from distributed systems in that this is interactions between co-located systems in a game framework I’m creating.

Here’s the video!

In the video stream, what I’m trying to accomplish is finding a way to share information from particular domains to be used in other domain. I mean, that’s the gist of it 🙂 The complicated parts are:

  • How do I keep domain information from leaking into other domains
  • How do I control access to the information without globally exposing it (i.e. avoiding something like a static global variable)
  • How do I make sure I have the right state when I want to go use it? (i.e. the systems run on a game loop, but some interactions that get triggered are from user events outside of the game loop)

My white-boarding skills in MS Paint are pretty rough, but I feel like it went okay! I’ll follow up with my findings, and hopefully get some programming videos put together to better explain some programming concepts.

Let me know what you think!


Timeboxing: TODO List 2.0!

I recently wrote about TODO lists and how they can help with focus now that many of us are working from home. I had a former colleague on LinkedIn mention this concept of “timeboxing” (which I think many people are familiar with the general idea) and how that can improve the effectiveness of a TODO list.

Here’s the post I made on LinkedIn sharing my blog article:

And the comment that came in right away from Graeme Harvey:

Graeme Harvey - Timeboxing

This obviously got me thinking because sure, Elon Musk is a pretty smart dude, but I also have a lot of respect for Graeme and his perspective on things. So I decided I’d try something out!

TODO Lists v1.0

My original TODO lists didn’t factor in any timeboxing techniques, but they had some benefits. The engineering mind in me says this is a great opportunity to do a little bit of a pros & cons analysis, so if you didn’t think I was nerdy before… Buckle up!

Pros:

  • Generally written out in the order I want (or need) to get things done. Acts a bit like a schedule in that regard.
  • Can have big and small items on the list.
  • Making progress on small items can help build momentum.
  • Let’s me record all the things I want (or need) to get done in the day and track if I did that or not

Cons:

  • No concept of how many things are too many or too few for an entire day’s worth of activity… There’s no timeboxing!
  • No concept of relative time spent on things (If I wrote “eat breakfast” and “Write a novel”, do they each get equal amount of time?)

TODO Lists v1.1

Okay we’re not quite yet at version 2.0 for these, but I took some of the concepts Graeme was referring to and I’ve implemented them every day since he made the comment. I’ve been trying to gauge how things have been going in terms of productivity and I’m already impressed. In fact, writing this blog post is part of my TODO list with timeboxing constraints (so meta, right?).

So the changes I made were very subtle but I’ll list them below:

  • I dropped the concept of putting in order what has to get done. Much of what I’m working on right now doesn’t have true dependencies, so trying to come up with an order for things doesn’t make sense (right now).
  • Every item I write down I put a time estimate on in minutes or hours. Literally everything. Remember I said little things like “Eat breakfast” can still be a TODO item that can help you feel like there’s momentum? Right. Breakfast, 10 minutes. Lunch, 15 minutes. Everything gets a time!
  • I tally up the total time my TODO list should take with timeboxing and do a gut check. I’m at least awake for 16 hours (typically people sleep like 8 hours, right?), but it’s probably closer to 18 hours. Because I’m starting off and don’t have great estimates, I’m ensuring I’m around the 12 hour mark for filling up my day.
  • I’m purposefully leaving some wiggle room in my schedule so that I can try incrementally building this out to be more accurate.

Nothing groundbreaking to implement, but what have I noticed so far?

  • Having a (relatively) small list of things I need to get done and getting to pick the next thing I want to tackle is kind of nice. A bit of flexibility is great!
  • The timeboxing really helps me make sure I’m focused on what I set out to do. 1 hour to review interview questions? Better not scroll on Instagram. 30 minutes to research a topic? Better not be on YouTube.
  • Some estimates for things are way off and some are very accurate! That’s okay though, because the following day I can adjust my estimates accordingly.
  • The overall feeling of being productive and making progress, for me at least, is even higher than it was before.

I’ve really enjoyed this small tweak and I’m hoping to get this to v2.0 status really soon 🙂 Thanks Graeme!


Xamarin Forms and Leveraging Autofac

I love dependency injection frameworks ever since I started using them. Specifically, I’m obsessed with using Autofac and I have a hard time developing applications unless I can use a solid DI framework like Autofac! I’ve recently been working with Xamarin and found that I wanted to use dependency injection, but some of the framework doesn’t support this well out of the box. I’ was adamant to get something going though, so I wanted to show you my way to make this work.

Disclaimer: In its current state, this is certainly a bit of a hack. I’ll explain why I’ve taken this approach though!

In your Android projects for Xamarin, any class that inherits from Activity is responsible for being created by the framework. This means where we’d usually have the luxury of passing in dependencies via a constructor and then having Autofac magically wire them up for us isn’t possible. Your constructors for these classes need to remain parameterless, and your OnCreate method is usually where your initialization for your activity will happen. We can work around that though.

My solution to this is to use a bit of a reflection hack coupled with Autofac to allow Autofac resolutions in the constructor as close as possible as to how they would normally work. A solution I wanted to avoid was a globally accessible reference to our application’s lifetime scope. I wanted to make sure that I limited the “leakage” of this not-so-great pattern to as few places as possible. With that said, I wanted to introduce a lifetime scope as a reference only to the classes that were interested in using Autofac where they’d otherwise be unable to.

  1. Make a static readonly variable in your classes that care about doing Autofac with a particular name that we can lookup via reflection. (An alternative is using an attribute to mark a static variable)
  2. After building your Autofac container and getting your scope (but prior to using it for anything), use reflection to check all types that have this static scope variable.
  3. Assign your scope to these static variables on the types that support it.
  4. In the constructors of these classes (keeping them parameterless so the framework can still do its job!), access your static scope variable and resolve the services you need

Here’s what that looks like in code!

MainActivity.cs

 public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity
    {
        protected override void OnCreate(Bundle savedInstanceState)
        {
            var builder = new ContainerBuilder();

            // TODO: add your registrations in!

            var container = builder.Build();
            var scope = container.BeginLifetimeScope();

            // the static variable i decided to use is called "_autofacHack"
            // so that it deters people from using it unless they know
            // what it's for! you could use reflection to find similar
            // fields with something like an attribute if you wanted.
            foreach (var field in GetType()
                .Assembly
                .GetTypes()
                .Select(x => x.GetField("_autofacHack", BindingFlags.NonPublic | BindingFlags.Static))
                .Where(x => x != null))
            {
                field.SetValue(null, scope);
            }

            LoadApplication(scope.Resolve<App>());
        }

The class that can take advantage of this would look like the following:

public sealed class MyActivityThatNeedsDependencyInjection : Activity
{
    private static readonly ILifetimeScope _autofacHack;
    private readonly IMyService _theServiceWeWant;

    // NOTE: we kept the constructor PARAMETERLESS because we need to
    public MyActivityThatNeedsDependencyInjection ()
    {
        _theServiceWeWant= _autofacHack.Resolve<IMyService>();
    }

    protected override void OnCreate(Bundle savedInstanceState)
    {
        base.OnCreate(savedInstanceState);

        // now we can use this service that we "injected"
        _theServiceWeWant.DoTheCoolStuff();
    }
}

Summary

Reading this you might think “well I don’t want to pollute my Xamarin code with variables that say _autofacHack, that’s gross”. And I don’t blame you! So this is to serve as a starting point for a greater solution, which I think is something I’ll evolve out for myself and I encourage you to do the same.

Things I’m focused on:

  • Minimize where “ugly” code is. A globally accessible scope on a static class seems like it can spread the “ugly” code to too many spots. This approach is intended to help minimize that.

    What are some next steps to make that EVEN better? Maybe an attribute so we can call it something nicer?
  • Write code that feels as close as possible to the “real” thing. Autofac usually allows us to specify services in the constructor and then automatically allows us to get the instances we need. This code is structured to be very similar, but since we’re NOT allowed to change the parameterless constructors, we resolve our services off the container there instead. And because it’s in the constructor, we can assign things to readonly variables as well which is a nice bonus.

The more implementations of this I go to use, the more I plan to refine it! How have you leveraged Autofac in your Xamarin projects?


  • Subscribe to Blog via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.

  • Nick Cosentino

    Nick Cosentino

    I have nearly a decade of professional hands on software engineering experience in parallel to leading multiple engineering teams to great results. I'm into bodybuilding, modified cards, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress