Showing posts with label Developer Diary. Show all posts
Showing posts with label Developer Diary. Show all posts

Thursday, 11 April 2019

A View On Redux (x-post from TIM Dev Blog)

tl;dr I like using Redux as it helps me keep state changes simple. There are problems to be aware of with Redux but overall my experience with it has been overwhelmingly positive. [This post was originally shared here]

The Benefits of Redux


What I like most about Redux is that I can use it to apply event sourcing to an entire React application's state.[0]This isn't unique to Redux at all. If you know of better alternatives, please let me know!

In this case, the events are actions and they are processed by reducers which update state. If all of the application's state is contained within Redux, then state can only change as a result of a reducer processing an action.

This is useful for me as I can think purely from the point of view of actions when I am thinking about state changes. I can reason about a series of actions and the resulting state. This reasoning transcribes neatly into test form, for example:
import myMathReducer from "./myMathReducer"
import {plus, times, minus} from "./myMathActions"

describe("my maths reducer", () => {
    it("performs basic arithmetic on my number", () => {
        const INITIAL_STATE = {myNumber: 5};
        const actions = [plus(1), times(2), minus(3)];
        const newState =
            actions.reduce(myMathReducer, INITIAL_STATE);

        expect(newState.myNumber).to.eql(9)
    });
});
I find this great because:
  • If the test makes sense to my pair[1]Does it makes sense to you? I'm hoping it is clear that we're asserting ((5 + 1) * 2) - 3 = 9, then I've gained confidence that I've got the state transitions clear in my head.
  • The test acts as documentation on what actions are available and how they change the state.
  • I've tested logic within my React app without having to go near mounting components and/or clicking buttons.

The Pitfalls of Redux


I've found Redux to be hard to use in anger at times. There are some nasty surprises which make for some very painful lessons.

The worst moment was bashing up against a bug for ages and finally finding out it was related to Redux blocking updates to components. This is when I learnt that the connect function has 3rd and 4th parameters you can pass to it. The fix was to mark my component as "impure"[2]The interesting implication here is that my code is not pious enough and the Redux Gods are smiting me for my heresy, via the 3rd parameter being passed to the connect function.

Luckily there aren't too many bumps along the road but they are quite noticeable. God forbid you ever accidentally give two actions the same type!

Redux is a big plus overall


I've found that, in the long term, using Redux has been massively helpful.

For me, the constraints imposed by Redux have helped me to keep things simple.[3]Lord knows I love the KISS principle

Redux changed the way I think and improved the way I write React apps. I recommend giving it a go yourself.

Thursday, 31 August 2017

Having Compassion - The Autobahn Metaphor

At the XTC meeting on Tuesday 23rd August I had the pleasure of meeting Sven! He shared with me a way of relating to other people’s world view and actions which centred around “how fast do you drive on the Autobahn?”.



The autobahn is the German motorway - famous for having no speed limit. 

On the Autobahn<link> there is no speed limit, a driver can as fast as they like. Say we are driving at 80mph, we could then say that we perceive:
  • 80mph is the CORRECT speed!
  • The drivers going 50mph are delaying me and it is a nuisance overtaking them.
  • The drivers going 180mph are dangerous and are risking crashing into me.

This leads to an interest situation where you can bisect the population of drivers as “agreeing” with your world view and those that are “detrimental” to you. Naturally this leads you somewhat into conflict… it would be GREAT if everyone just drove at YOUR speed right?!

How do we overcome this and actually relate to all the other drivers on the road then?

Monday, 7 August 2017

Developer Diary: Starting At TIM Group

Today was my first day working at TIM Group! I'm humbled to be working with so many enthusiastic and intelligent people. The culture and way of working at the company is a massive departure from what I am used to. Everyone in technology is responsible for themselves, trusted to get the work done and nurtured to improve. People understand the value of happiness and real work/life balance.

Even after a single day there I am seeing and feeling the difference. Little things like:

  1. We managed to break something as I was being onboarded. A colleague spotted this before us, fixed it and notified us. No fuss, no muss.
  2. For lunch we took 90 minutes and sang sea shanties, it was silly and glorious. It could have been embarrassing but it felt like a safe space :)
  3. Everyone, including the CEO, started walking out at 5.30pm
  4. For 7 years I've come home and gotten changed. There is relief when I can take off the suit. Today I walked in the door and I was already comfortable in my skin.
Exciting times :)

Tuesday, 4 April 2017

Corda - First Impressions

Today I was lucky enough to attend my first day of training on Corda, an "an open-source distributed ledger platform designed to record, manage and automate legal agreements between businesses".

Roger Willis and Richard Green did a fantastic job and I walked away excited for the 2nd day of training tomorrow. Between then and now I've got a whole load of thoughts/questions on my mind...


Corda isn't a traditional blockchain

Corda doesn't have the concepts of blocks or mining that you will find in Bitcoin and Ethereum. Transactions are purely point-to-point and validated individually in Corda. This stands opposed to the others which group up transactions and calculates a hash for all of them together (turning them into a block).

Immutability

What is there to stop the transaction history being modified? Well transactions are digitally signed and assuming all parties keep their private key safe, no one can realistically change history. On top of this, the ledger isn't reliant on mining and is designed to be immutable. This means that the only change parties expect to see is on current state.

Data Privacy

Transactions aren't broadcast globally to the entire network and only sent on a need-to-know basis. This protects against data leakage as parties in the network don't have free access to monitor who everyone is interacting with. Keeping the data contained also limits the damage if your private key is somehow compromised because your encrypted data isn't freely available to a potential attacker.

Tuesday, 22 March 2016

Flappy Whale v1.3.0 (Animated Whale)

It has taken us this long but our Flappy Whale is now actually flapping when you tap :D Play the game and check it out yourself by clicking on the show button below!


Flappy Whale! v1.3.0 - ewry games

We toyed between the idea of having the Whale constantly flapping or having it flap only when you tapped. In the end we liked having it flap whenever you tapped as it provided extra positive feedback to the player. Note the Whale will remain stationary as it plummets, reinforcing the need to tap/flap.

Animating the Whale and the glowing rocks has really given me a profound respect for the intricacies involved in animation. It's fun to see how a handful of static images can produce motion but incredibly painful to tweak all the timings to produce the perfect effect.

Thursday, 17 March 2016

Flappy Whale v1.2.0 (Pulsating Rocks! - ewry games)

We have decided to pivot and changed the flying obstacles to floating rocks :D. Try to enjoy the gentle pulsating glow of the rocks without crashing right into them! Click the show button below to launch the game.


Flappy Whale! v1.2.0 - ewry games

We're starting to wrap up the game now and there are only a few more visual items we need to tweak. Depending on feedback I may ramp up the difficulty for the Killer mode as well :P

Tuesday, 8 March 2016

Flappy Whale v1.0.0 (ewry games)

 @RumziYousef and I are proud to present v1.0.0 of our very first game: Flappy Whale!


Flappy Whale! v1.0.0 - ewry games

Rumzi has been busy creating some awesome artwork to help put the finishing touches to our project. I've also added 3 difficulty modes to the game as well :D


  • Checkout the great new background and our floating skyscrapers.
  • Try out the Easy, Hard and Killer difficulty modes.
Hope you enjoy it!

Monday, 22 February 2016

Flappy Whale v0.3.0 (Graphics Update - ewry games)

We have finally started introducing proper graphics into the game :D You can know play as the "Sky Whale" and flap your way through the skies!


Flappy Whale! v0.3.0 - ewry games

Note that I've bumped the resolution and changed the aspect ratio to make the game better suited to modern displays :) The scrolling background is very simple but I was very pleased with how easy it was to put together. We are definitely going to start polishing everything a lot more, our current targets are:

  • Introduce new difficulty modes
  • Update the whale graphics
  • Add new fonts

Saturday, 20 February 2016

Flappy Cube v0.2.3 (Highscore - ewry games)

This small update to the game has cleaned up the HUD and introduced a Highscore!


Flappy Cube v0.2.3 - ewry games

I managed to uncover the "pipes don't spawn" bug in the Tutorial. This old bug was present in the spawning logic for the pipes. When I created Tutorial, I simply copy and pasted the code over. This bad practice came back to haunt me, code duplication is the devil! I've known killed the duplicated code and there is a single piece of spawning logic that is configurable now :)

There is a choice on spawning pipes/ships randomly or in a fixed position.

Sadly the Highscore doesn't persist if you refresh the game :( This will be something we look at once the game is more fully fledged!

Wednesday, 17 February 2016

Flappy Cube v0.2.2 (Bug Fixes - ewry games)

Fixed an issue where the game wasn't restarting properly after colliding with a pipe.


Flappy Cube v0.2.2 - ewry games

It seems unpausing may not work properly if you attempt it just before switching scene. Another "gotcha" to add to the list for Stencyl :(

Flappy Cube v0.2.1 (ewry games)

We have a minor version bump for Flappy Cube! Now we open off with a start menu and I've introduced a basic tutorial :)


Flappy Cube v0.2.1 - ewry games

I found that there was shared logic between all these buttons to switch the scene and draw the button text in the right place. Behaviours in Stencyl seem to be the best way to go when trying to encapsulate/share logic.

Switching Scenes Behaviour

Behaviours can expose configurable attributes and they really help in reducing the amount of duplicated code. Sadly there doesn't appear to be an easy to compose behaviours though.

Flappy Cube v0.1.2 (Scoring Added - ewry games)

This patch update introduced scoring.


Flappy Cube v0.1.2 - ewry games

I implemented this by firing an event every time one of the pipes left the screen, as that coincided with the player jumping paste them successfully.  The out of the box "actor has left the scene" event in Stencyl didn't seem to want to play ball with me at all though. It seemed to fire really inconsistently and I can only assume I did something wrong with regards to the scene boundaries. In the end I went with writing a custom event that the pipe would fire once it detected it was out of bounds itself.

To improve on this design, I would instead look to make a specialised collision zone/region on the pipe where the gap is. This would detect when the player successfully goes through the gap and increments the score. Doing it this way would remove the dependency on fixing the player's lateral position on the screen. I'd assume there would be some performance overheads for that solution though.

Speaking of which, I'd really like to find out more about performance testing and unit testing games more. Stencyl seems to have very poor support in both areas but Haxe does have a unit testing library within it...

Sunday, 14 February 2016

Flappy Cube v0.1.1 (ewry games - Stencyl)

Very excited to have built this basic game completely from scratch!


Flappy Cube v0.1.1 - ewry games

This is a very raw version and the plan is:
  • Fix bug where "pipe" appears too off the ground.
  • Add Scoring
  • Introduce theme
  • Start the game on a separate menu screen
I'll go more into the implementation details and my experience with it all next time :)


Thursday, 11 February 2016

Stencyl Crash Course 2 - Space Invaders

Followed the 2nd Stencyl Crash Course and created a flash version of Space Invaders.

Note that you use Z to fire! The game lacks polish but it is functional. I haven't done any proper play testing or balancing, right now it feels a little too difficult. Here is a short video demonstrating the different ways to lose and win:

"Space Invaders" In Action

Tuesday, 9 February 2016

Stencyl Crash Course

Spent a night messing around with Stencyl and managed to create a basic Flash game. Sadly all you can do right now is:
  • Run/jump around
  • Kill enemies Mario style. 
  • Die by touching an enemy.
  • Die from falling off.

(click to launch Flash game)

This was adapted from the 1st Crash Course on the Stencyl website. The tutorial is very interesting and it walks you through all the major components of the game engine in less than 30 minutes.

What is ace about Stencyl is that it has an incredibly low barrier to entry. I'd imagine it would be a great tool for teaching anyone about coding/games development as you can pick it up without any prior knowledge. This also makes it ideal for graphic designers to create games when previously they might not have had the programming skills to do so.

Stencyl Behaviour Editor (Coding without the code!)

Wednesday, 26 August 2015

Code Review - Where To Start

I really enjoyed reading: What To Look For In A Code Review - it touches on something I do everyday and is a skill I really want to hone.

One of the things I have learnt is code review should never start with looking at what the code does or even how it does it. Take this snippet for example:

There are many things you could comment on:
  • The insane mixture of camelCase and underscores
  • A curious use of the package-private visibility
  • Rather disturbing presence of the Singleton annotation
Whilst all these questions are very valid, without proper context they may prove to be completely redundant! Building up this context is where a code review should start, establish:
  • Why is the code needed?
  • What is the underlying problem being solved?
This information shouldn't be limited to the code review either, the code should communicate this for any future readers.

Sunday, 30 November 2014

London Java Community - Open Conference 2014

I have had an absolute blast attending my 3rd LJC Unconference! As always I have learnt loads and this year I also had the opportunity to help others find out some nifty things as well :)

Discussion - Concurrent Applications In The Modern JVM & Using Akka

The last four letters of my name are still being horrendously neglected
I took the plunge and got roped in by our funnest software evangelist to answer the call of two developers interested in Modern Concurrency and Akka (@Simon - remember it is Edward - not Ed! :P)

When I originally agreed to do this in the morning, I was hoping for a small group of people to show up and we would have some simple roundtable discussion... Somehow at 3pm I found myself in the main room standing in front of thirty or more people!!! Luckily I had "The One" with me and the LSCC Roundtables have taught me how to lead a discussion (much love to Samir, Sandro and Tom for this!)

To start the discussion, I gave a little rant about how manually wiring up multi-threaded code is really hard and the pitfalls we found when using Akka in BetterRev - an Adopt OpenJDK project to change the way we change Java. From there we all talked about our various experiences and there were some great insights from people on a range of concurrency topics/tools. I really enjoyed the session and hope people got something out of it :)

Developing As A Developer - Getting Involved With The Community

The number of first time attendees to the conference was quite high and I got to speak to a bunch of developers that were just starting their professional careers. My advice to everyone was to get involved with the community, even if you by just blogging! Sharing the interesting things you have learnt is a great way to ensure you reinforce that learning and can lead you to learn new things.

One of the funnest and most rewarding things you can do with the community is to hack together. Attending code dojos and hands on sessions gives you the opportunity to learn more about anything from sweet IDE shortcuts to SOLID software design principles. I cannot recommend these enough!

Conclusion

Another year has passed and I'm already excited for the next conference. My thanks to all that gave me such invaluable advice again and to everyone involved in organising and running the conference!

Sunday, 6 April 2014

Ranting About Retrospectives

Following on from Thinking About Code, I have since participated in a retrospective and the introspective process has inspired me to rant :)

Free Your Mind

One of the problems we had in our last retrospective was we were very much unprepared. Many of us did not have proper notes and worst of all there was a negative mindset toward the whole retrospective process. This time around everyone actively prepared and everyone was onboard with the idea of using the retrospective to improve the way we work. A positive viewpoint really works wonders and resulted in a much higher quality of the discussion :)

Bricks Without Clay

As the famous Sherlock quote goes, you can only put theories together when you have data. This principle holds true for any scientific process, including retrospectives. This is computer science we are dealing with after all!

In our case, data is as simple as our likes and dislikes about our work. However as there is a month between our retrospectives, forgetfulness is a major issue. Ongoing observation is the key here, we all need to constantly seek out analyse the way we work. This can be as simple as jotting down notes on what you feel is good/bad as you work. 

Get To The Point

Open ended questions like "what did you like/dislike this month?" are great for getting people to open up but can lead to rambling. In an ideal world you want everyone to distill their feelings beforehand and provide short and sweet summaries. The key is to move beyond raw emotions and use unambiguous statements: "I don't like rambling" is better stated as: "I like people being concise".

Mixing It Up

When undergoing the process of self reflection, it is important to have compare and contrast against others. Trying to view things from an outsider's perspective can throw into light problems/opportunities you would have otherwise missed. In our case, reviewing a piece of code written by an applicant threw up a lot of interesting viewpoints.

Conclusion

Overall I feel that retrospectives are having a positive effect on the team and the change in mentality is very refreshing. We are all looking at ways to better ourselves, both individually and as a team. The next steps are to achieve the things we have talked about, which is always easier said than done.

Friday, 31 January 2014

London Code Dojo 30

Monday was London Code Dojo 30 and this time we were back in Barbican with the lovely people at valtech

WHAT WENT DOWN

The kata for the evening was based upon Fibonacci numbers... but with a twist! The problem was centred around Fibonaccimal Numbers (link) which use the Fibonacci numbers as a base for representing numbers. So taking 1, 2,3,5 and 8 as a base, we can represent 9 as 10001 or 01101. As you can see, some numbers can have multiple representations and this added to the complexity of the problem. For the majority of the evening I paired with Rob and I found it really valuable getting his insight into the problem! The code we produced for the night can be found here: https://github.com/arkangelofkaos/CodeDojo30_Fibonacci

MY IMPRESSIONS

Nothing beats a good plan

More so then anything else, I came to appreciate the value of having a solid plan. Having a high level design which everyone agrees will solve the problem is incredibly important. Test driving code doesn't magically produce well designed algorithms.


LESSONS LEARNT

Decompose complexity into simple functions

Functional concepts supplement object oriented coding in a fantastically seamless way. When dealing with collections or calculations it is surprising how  higher order functions like map and reduce translate to how you naturally think about the problems.

For instance, to produce all the Fibonaccimal representations of a number, you can use a two step process:
  1. Find all unique ways to express that number as a sum of different Fibonacci numbers 
    • For example: 3 is [3] and [2+1]
  2. Translate each way into the corresponding Fibonaccimal 
    • [3] is 100 and [2+1] is 011
These steps are both mapping a number to a list of lists, then each list to a String. This is reflected in the code below:
return sumsCalculator.fibonacciSumsFor(number) // Step 1
                             .parallelStream()
                             .map(toStringCalculator::fibonacciSumToString); // Step 2

Suddenly I've decomposed an abstract problem into two concrete functions which I understand and can test drive!

Perhaps this is the crux behind solving all problems. Reduce the complexity until the solution is series of simple steps. Needless to say, making things simple is not simple... But there in lies the rub :)

Wednesday, 4 December 2013

London Code Dojo 29

Monday was London Code Dojo 29 and this time we were in Shoreditch in moo.com office. Not the most productive dojo but I learnt some philosophical lessons about myself and my code!

WHAT WENT DOWN

The kata for the night was "Rock Scissors Paper" but this time there was a twist in that we had to implement HTTP servers to play the game. The idea was that you would have two "player" servers which responded to requests with a move. On top of this you would have a "referee" server presiding over a game and deciding who won.

The specification was a little bit vague beyond this and we wasted a fair amount of time getting to grips with the problem. Overall I felt the added complexity of dealing with HTTP hindered the learning experience. I paired with Ian and what code we did manage to produce is here: https://github.com/arkangelofkaos/CodeDojo29_RockScissorsPaper

MY IMPRESSIONS

Understand the scope of the problem

Getting a grasp of the problem at hand is incredibly hard in almost any situation beyond the very simple. Accepting the fact that you are unsure on how to proceed and having an "iteration zero" for setup and learning is invaluable. On the flip side this needs to be balanced with over-designing the problem...

Dealing with new technology REALLY slows you down

I have rarely dealt with writing RESTful services in Java from scratch and approaching the problem was difficult. I reckon we lost a good half an hour getting our heads around whether we had to deal with HTTP errors and what level of testing to start with.


LESSONS LEARNT

Discover a solution with small steps
When pairing with someone new, even if you are both used to approaching a problem top-down with overarching integration tests, it can be more productive to take some small steps to begin with. This way you can get used to each other's TDD quirks and flesh out any misunderstandings. 

Focus hard on learning

As with most things, it can be very easy to get caught up in what you are doing and lose sight of why you are doing it. In dojo's I am still far too focussed in the problems and not thinking hard enough on good practice. Perhaps next time I will make a plan for how I am going to learn and see if I can strictly stick to it...