Forem: Alex Shannon

Could AI take my job?

Alex Shannon — Sat, 22 Apr 2023 19:44:48 +0000

Probably not … at least not yet. Some words I may end up regretting but hopefully won’t! I like many have been entranced with some of the incredible progress of AI over the last few months. When Microsoft launched Copilot there was much hysteria about this changing developers' lives forever and that many of us would be made redundant as teams were downscaled, extra hires not being needed and so on but in reality not much changed for us. I, for one, didn’t lose my job fortunately and in fact, despite most of the team agreeing that it would be useful we had more pressing concerns at the time, and this was sidelined.

Now with the impressive progress of ChatGPT, we can no longer ignore the growing sense that AI will have to impact our lives, but how is still very much in argument. As you might expect from a group of techies, most of my coworkers and I jumped on and started playing around as soon as we could. And again, we were impressed. But after using it for some time and watching its progress there isn’t the sense of anxiety that this will cut us out of our jobs but instead enhance them. Currently from what I’ve seen and experienced from these tools is that there is a skill in knowing how and what to prompt to get a reasonably decent answer, that’s not to say that a half-thought-out question won’t get a response, but it might not be what you really need. I liken this to a running joke I’ve heard many times of people stating that one of their skills is “Googling” referring to the ability to correctly search and find the right answer to potentially difficult questions using the Google search engine. I found this kind of sentiment to be true in the ChatGPT experiences I had and with other similar AI-powered tools; Midjourney and Microsofts Copilot.

Midjouney is an AI technology company focuses on generating images from prompts to a discord bot which then posts the results back. After following many chats, I found a re-occurring trend, many times people would re-post prompts with subtle changes. I for one did this on several attempts with no success, I gave it a simple prompt “happy coffee cup working on a laptop as a sticker”, I expected something cartoony that depicted a personified coffee cup with perhaps tiny arms working away at a tiny laptop of relative size to itself all on a small sticker. I would expect that many people would probably think the same, but after trying several similar variations of this prompt the closest I got was
ai generated image of a cartoon laptop next to a coffe cup shaped object smiling holding a coffee cup
Midjourney generated image of a happy coffee cup holding a laptop

and many times I ended up with just a coffee-filled pc with a cartoon smiling face put on top.

But having said this, I was still impressed with the results and especially given the time frame, it’s entirely possible that I could have commissioned an artist with the same request of a happy working coffee cup and been given the same result. The difference however was that the AI response was almost instantaneous. And that quick feedback loop had me thinking of what it was that I actually wanted, things like; what style was it that I needed, would kind of coffee cup did I want, where was the coffee cup placed?

It’s a similar story with Copilot, however, this tool focuses on predicting the next piece of code (be it a single word or many lines). Most of the time this tool is surprisingly good at calculating what I would be typing next, however, on quite a few occasions I’ve had to go through and correct the generated output. It’s a huge improvement from its predecessors in predictive code but still quite a way off from being a complete replacement for a developer. The largest and most significant change it has brought about in my workflow has been a dramatic decrease in writing simple menial code (like debug logs) and more time thinking about how to solve the actual business problems.

So it's from this experience that I can say I’m excited about the introduction of AI tools into coding. As I mentioned at the start, I don’t think they will replace my job right now, and possibly not for a little while. But I do enjoy what they bring to my day-to-day job and I’m fairly confident they will continue to increase my productivity. Helping to write out the common repetitive bits of code leaving me more time to focus on solving the bigger picture.
We’ll see if I end up eating these words though.

Storing url search queries with React and Typescript

Alex Shannon — Fri, 19 Oct 2018 07:31:23 +0000

I was recently looking into storing some values in the url to enable users to pass urls around and load the app into a certain state. Simple enough, though complicated by the fact that the app also uses redux to manage the apps state as Redux will not be covered here we will mimic this behaviour with state instead.

Want to see the code used? Visit Code Sandbox

Setup

So to start off we need to make sure that we have react-router-dom and react-router installed and our app is using react-router-dom (if you need to help with this Paul Sherman has a great article on the basic setup. We also need to make sure that the component that we want to capture use the search parameters has exposure to them via the props so we need to add RouterComponentProps to the prop type and then when exporting the component we need to wrap with withRouter( ).

import {RouteComponentProps, withRouter} from "react-router";

class SimpleMainComponent extends React.Component<
  RouteComponentProps<any>
{
...
}

export default withRouter(SimpleMainComponent);

Getting the search query

After the setup is done we will be able to access the route properties, the one we are interested in is the location.search properly.

this.props.location.search

this comes through as a string, so when we navigate to "http://.../user?name=john" it will mean that location.search is "?name=john". This is not very helpful to us when we want to grab a specific value from this. This is where the URLSearchParams type comes into play

let search = new URLSearchParams(this.props.location.search);

this encapsulates the logic required to pull out values of the search query based on a key.

let search = new URLSearchParams(this.props.location.search);
let name = search.get("name");

when used with the url that we had above, "http://.../user?name=john", we get name equalling "john". Perfect, we're ready to start piecing together a simple component to consume values from our search query.

import * as React from "react";
import { RouteComponentProps, withRouter } from "react-router";

class SimpleMainComponent extends React.Component<RouteComponentProps<any>> {
  render() {
    let name = this.getName();
    return (
      <div>
        name is: {name}
      </div>
    );
  }

  getName(): string {
    let search = this.getUrlParams();
    return search.get("name") || "";
  }

  getUrlParams(): URLSearchParams {
    if (!this.props.location.search) return new URLSearchParams();
    return new URLSearchParams(this.props.location.search);
  }
}

Statefulness problems

The next step starts the problem. If we are using redux along with this we have the problem that we might read the name, store it in redux, navigate to a different area of the app then return to this component later. In this case the url is now wrong, though we might get to "/users" our search parameter has gone. We might have the users name set correctly in redux but the search parameter is misaligned with what is being displayed and therefore if we refresh the page we will get a different result shown. In this situation we could possibly want to append the search query string on to the end of the route when we come back to this component. To do this we will need to store that string somewhere.

If we revisit the component that we've just made we can mimic this behaviour by putting it into state. The specific behaviour that i want to draw attention to is the re-rendering being triggered when the state or props change. A problem we quickly run into is continuously re-rendering the component if we simply put the search paramerter into state like so

  state = {
    search: this.props.location.search,
  };

  componentDidMount() {
    this.setState({ search: this.getUrlParams().toString() });
  }

  componentDidUpdate() {
    this.setState({ search: this.getUrlParams().toString() });
  }

This is a clear violation of setting state, but one that can be easily missed, especially if you break out the logic of getting the search parameters, finding the values you want and updating the state. What is the solution?

 componentDidMount() {
    let search = this.getUrlParams().toString();
    this.setState({ search: search });
  }

  componentDidUpdate() {
    let search = this.getUrlParams().toString();
    if (this.didQueryChange(search)) this.setState({ search: search });
  }
...

didQueryChange(search: string): boolean {
    return this.state.search !== search;
  }

with this check now in place we can saftely update our props or state without causing an infinate re-rendering loop

import * as React from "react";
import { RouteComponentProps, withRouter } from "react-router";

type State = { search: string; count: number };

class MainComponent extends React.Component<RouteComponentProps<any>, State> {
  state = {
    search: this.props.location.search,
    count: 0
  };

  componentDidMount() {
    let search = this.getUrlParams().toString();
    this.setState({ search: search });
  }

  componentDidUpdate() {
    let search = this.getUrlParams().toString();
    if (this.didQueryChange(search)) this.setState({ search: search });
  }

  render() {
    let name = this.getName();
    return (
      <div>
        name is: {name}{" "}
        <button onClick={this.increaseCount}>count: {this.state.count}</button>
      </div>
    );
  }

  increaseCount = () => this.setState({ count: this.state.count + 1 });

  getName(): string {
    let search = this.getUrlParams();
    return search.get("name") || "";
  }

  didQueryChange(search: string): boolean {
    return this.state.search !== search;
  }

  getUrlParams(): URLSearchParams {
    if (!this.props.location.search) return new URLSearchParams();
    return new URLSearchParams(this.props.location.search);
  }
}

export default withRouter(MainComponent);

One of our big problems when comparing is that this.props.location.search is not equal to new URLSearchParams(this.props.location.search).toString(). This might seem obvious but this has caused heachaches before as methods such as getUrlParams() are so easy to use, handling the safe retrial of the search query, that it's tempting to do something like

this.state.search !== this.props.location.search;
...
this.setState({ search: this.getUrlParams().toString()})

but these evaluate to do different things

this.props.location.search = "?name=john"
this.getUrlParams().toString = "name=john"

you can set the search string state to either one, but be careful that when you use the same retrial method to for both the comparing and setting of the stateful string

Last tip

explore the URLSearchParams type as it does more than just read the values, you can use this type to also set values, for instance

let values = this.getUrlParams();
values.append("count",this.state.count.toString())
this.props.history.push({search:values.toString()})

In Summary

It's fairly quick and painless to get started with accessing the URL search parameters in react with typescript, we just have to remember to use the URLSearchParams type when getting and setting values. We can easily run into problems when we start trying to add this into the state of our application and therefore need to guard against infinite rendering problems.

The code for this tutorial can be found in github or play with it on code sandbox

This Week #1: The Big-O no

Alex Shannon — Fri, 28 Sep 2018 20:06:31 +0000

Big lesson

Last week I listened to a podcast about algorithmic complexity. In the podcast they talked about Big-O notation and what this means running through examples and describing what differences there are (performance-wise). Having not taken a computing course academically I had never been taught about this and in all my previous jobs this has never really come up. Although I had heard the term thrown around here and there I had always shied away from taking the time to learn it. I had convinced myself that this was a complex subject and that I didn't have time to learn about it, after all no one had really raised it as a concern so why would it be a problem?

But after an hour of listening I had been given a brief taste of the Big O notation and really it wasn't as hard as I had built it up in my mind (credit does of course go to the presenters of the podcast who managed to break it down into easy to digest chunks). I had already started to think about places in my code where I was creating potential O(n^2) problems and thinking up ways to solve them.

Small change

So this week I spent some time reviewing some of the code that I knew I had recently written that was going to be a potential problem. After ten minutes a much better solution was in place and whats more I had been given enough information and terminology to explain what the problem was and how the code change addressed it

The problem was that I had two collections. One I had to iterate over, so this is already an O(n) problem. But then for each one of these I was iterating over the second array finding all the instances that matched the same id only to then take the first one returned from that operation.

collection1.map(c1=>collection2.filter(c2=>c2.id===c1.id)[0])

example code only!

Ok so it's not an O(n^2) problem but it still felt like a problem. And it certainly wasn't an O(n) problem anymore. I could feel that this was creeping into the 'red' zone.

The solution? Change the second array to a standard js key:value object then look up the value as a property.

collection1.map(c1=>collection2[collection1.id])

example code only!

It wasn't much but I knew that this was now more of an O(n) problem where we should only be going over each array once. And since the first and second collection could each contain hundreds of items it would most likely also prove to be faster.

Next Week and beyond?

I plan to continue to improve my understanding of the Big O notation. At least now I have an appreciation for its purpose as well as breaking through the mental barrier I had put up. I also plan on getting the Big O Cheat Sheet(already on my Christmas list)

p.s podcast was by coding blocks if you haven't already check them out they're well worth a listen too, they run through this and many more programming concepts!

Less clutter, More information please

Alex Shannon — Fri, 21 Sep 2018 20:48:31 +0000

A while back my Nexus 5x died and I was very, very sad and begrudginly I got a new phone, well because I had to. So I decided to take this opputunity to re-organise my phone and the layout.
The phone I got was a WileyFox Swift 2X. I quickly installed Google Now launcher and was back in familar territory.

The change I decided was that instead of having many screens which had many small app icons on them (around 4 screens in total) I would instead limit myself to half the home screen for app icons (the other half being the clock widget I have) and only allow extra screens to show widgets.

Why?

Here's the thing, I was finding it harder and harder to get to the apps I wanted and I was also losing track of what apps were on my phone. Also I couldn't even remeber their names just the icon. This was a problem as when I had to reinstall a bunch of them (the ones not installed through the plays store) I ended up spending more time than I needed trying to recall what they were actually named.

So now my screens only display information to me, I can quickly swipe left and right to see actual information. If I need more information I can tap into the widget or I will just search and launch the app from the main app area.

Pros

I find myself quickly deleting any app that I don't need. My home screen feels less clutered and I spend less time trying to find apps on the home screen or coming up with the next awesome new folder layout. I'm also feel less templated to play distracting games that would otherwise be sitting there inticingly

Cons

I have since started to want more apps on the main screens so maybe I need to increase my area. As well many apps don't support widgets, instead doing the long press technique to show more options which I lose out on when they're not right there on the main screens.

A c# dev starting a Java course

Alex Shannon — Fri, 21 Sep 2018 19:58:39 +0000

I have started a module with the Open University where I am to learn OO concepts through learning and using Java. As personal documentation as well as interest for anyone I decided that I would document my journey.

Before we begin, my background for the last 4 years or so has been specifically using c# in my profession, first as an automated tester then as a software engineer so I am familiar with the OO principles and concepts. Though I will admit my theory lacks because I did not go to university or study any CS course previous to the one I'm on now. I have used other languages but Java is not one that I have really touched but being so similar to c# I have heard it talked about many times so I was clued up on at least some of the differences I would face when learning it.

Below are my first discoveries as I embarked on the course.

I want my IDE

The tool of use by the University is BlueJ. And although I can see the appeal for those that are learning OO and Java I'm having a real battle coming from Visual Studio and VS Code. Where is my Intellisense! It feels like a step backwards and an experience that is not relative to the real world.

Collections are a lot harder!

Ok I admit maybe Linq has spoiled me but working with collections seems unnecessarily hard. It seems like there is a lot of code required to just create a new List and iterate through this. Maybe this is just me and I hope that in a few weeks I'll be laughing at this and ranting in the comments about how easy it in fact is.

Where is my entry point

I ran into this when I wanted to create a hello world console app. After a quick search it turns out that it’s just the method

public static void main() { 
...
}

and this can be in any class. I guess this can be both a pro and a con.

Always Type

I'm a big user of var in c# and pretty much any keyword that is general and gets the compiler to work out the type. But in Java you must set the Type everytime. Not a big thing and can in some cases be beneficial making sure the variable is definitely the type you expect

String name  = "John Doe";

Capital String and Boolean, lowercase int?

From what I seem to be able to gather the types have different casing to each other. In c# it's pretty much all lower case
c#

string Name;
int Age; 
boolean IsVerified;

but in Java they are

String name;
int age; 
Boolean isVerified

More casing issues

This one I'm used to as I've worked with JS and TS and also just aware of it anyway but method names and instance variable (in c# known as properties) start with lowercase


private String name;

public void setName(String name){
 this.name = name;
}
...

Explicit Getters and Setters

I was shocked to be told to have to create and expose getters and setters methods for each instance variable I wanted to expose and manipulate. I much prefer c#'s way of handling this

public string Name { get; set; }

Java

private String name;

public String getName(){
   return name;
}

public void setName(String name){
   this.name = name
}

To Sum up

It may seem like I'm complaining about Java and perhaps I come across as a c# fanboy but really what do you expect, that's my world and has been for a few years now so it's going to take some adjustment.
I hope to keep documenting my learnings as I delve deeper into the world of Java, after all there is a reason it's still so popular!