A software developer and avid cook in Sydney, Australia.

I'm currently a third-year student studying computer science at 

 to see what I've been up to!

To contact me directly, fill out the form 

John

This project was created by team Placeholder consisting of 

Task Master was created through the undertaking of 

, the capstone project course.  The idea happened to be one of the many selections that were available, however as a team, we decided to select this particular idea for a number of reasons:

Our familiarity with the problem of managing day to day tasks

A few of us had already used competing apps within the space (Todoist, google tasks, etc...)

Our already established ideas for possible implementation and additions to the problem's scope (ones that I will mention later)

After our first few meetings, it was decided that due to our uncreativity (our team's name is "placeholder"...), the app would be named "Task Master", exact to what was provided in the project's specification.

The project itself proposed to solve numerous amount of issues that included allowing

Large scaling teams to assign and manage tasks within the workplace

The estimation of busyness (yes that is a word) based on assigned tasks 

A network management system that allows for users to add and remove individuals that are currently within their workplaces

Provided 10 weeks, we were to fully build the system, walk through our implementation and deliver on a number of reflections and reports during the process. We were also required to include our own additions to increase the novelty of the product with us introducing two new feature requirements;

A chat messaging system to allow users to directly communicate without the need for an external platform

A machine learning model that would allow for the generation of busyness values based on past user data (periodically fed). 

The frontend in its entirety was built by our frontend team (James Dang and Jake Edwards).

Created with React with Redux state management and styled by styled-components, every effort was placed into ensuring that the platform could be built as soon and as quickly as possible.

However, during the time that the initial backend endpoints were developed, the team completed the initial mockup for Task Master as well as the prototype to work as the base for the initial implementation. 

Alongside the requirement for building the frontend, the addition of the chat messaging feature meant that a messaging system had to be built in order for the user to transmit messages to other users. In this case, a real-time messaging server was built using socket.io that was run concurrently with the frontend and backend to act as middleware in enabling the transmission and restoration of messages between users.

The backend in its entirety was built by our backend team (Edward Gauld, Jaydon Tse and Myself).

With the attitude of efficiency being king, the backend team decided on the use of Django and its rest framework on the main backend technology used to implement the features needed. This was selected due to the high modularity of packages that accompany Django which allowed for shorter development times, increasing the efficiency of the backend development process. There were also a number of open-source packages used in conjunction with Django within the backend itself including:

As well as the integrations of the API endpoints required for the function of Task Master, the additional requirement of Machine Learning generated Busyness estimates required for the production of an entirely new sub-project within the Task Master scope. This project was named the "Busyness Delta Project", with the creation of the Machine Learning Model handled by Jaydon Tse, and integration with the backend done by myself. 

You can find the specifications of the Delta Project 

Alongside the Machine Learning integration, there were functions built to enable the model to self-update and become self-sufficient with the use of user data anonymously utilised to sharpen the accuracy of the model. This model, as well as feedback forms specific to users, were regenerated/reset every Saturday via Django-apscheduler.

As with all projects challenges came along the way that had to be solved. The only difference, in this case, is that we documented them this time around.

Some of these documentations have been included below and taken from the final report. You can read the entire report 

Initially, we had planned to poll the servers constantly to retrieve and send messages that would give the illusion of real-time. However, this would have heavily congested the server, even at a small scale, and could potentially show messages out of order.

For its first implementation, we planned to use the Django channels package to implement messaging. It would also make sense to integrate messaging with the backend code as it would centralise components together. However, the package was unintuitive when it came to building the private messaging service, as it required many workarounds to get the foundations working. Also, the feature of showing users being online/offline also seemed too big of a challenge, which almost scrapped the idea of integrating real-time messaging.


Instead, we experimented with Socket.io, which would not be integrated with the Django server and instead act as its own standalone Node.js server. While it seemed sceptical to implement it this way, since it decentralises code, even more, it turned out to be the more optimal solution.

The Socket.io server was able to create socket ids that were uniquely assigned to an individual web browser. These socket ids allowed messages to be redirected to the correct users, which showed in real-time as well. Socket.io also allowed the broadcasting of currently online users, which was how we were able to implement users being online/offline.


Busyness estimates and the acquisition of initial data 

The lack of realistic data reduced the capability and accuracy of the predictions that were made from the model. As the generation of the model depended upon large amounts of data to provide a higher level of accuracy. However, due to the unavailability of accurate task data within our project’s ecosystem, the random generation of data was utilised in training the machine learning model. This meant that the generated busyness value was not accurate and resulted in irregular behaviour such as busyness being unresponsive to large changes in user workload. Though this issue is mitigated following the induction of user-generated data, it still poses an issue during development and prototype testing/verification. 

Through thick and thin, our team completed the project in its entirety receiving a High Distinction mark for our efforts. The project is currently not hosted anywhere but you yourself can take a look at the source code 

, alongside any of the other uni work that I have chosen to open source.

The final demonstration product was run with Linux via a VM. All instructions are located within the repository's readme.

Ultimately I believe that this project has taught all of us a little of everything when it comes to software development. From strengthing my own personal time management to team coordination skills and even how to write code better, the project has been an invaluable experience that will forever be on my transcript. 🎓

Task Master, a project that improves people's workflow, one task at a time.

Task Master

Scribee, a journey to find a better way to work.

, Scribee is the solution to a problem that is eminent throughout the world or at least for anyone who does work on the web that is;

How can you take notes better, and not have them slow down your workflow?

This was the problem that the engineers at Accenture gave us to solve. We had to find a way to build a product that 

Allowed people to research and take down notes better 

Increase the efficiency of how people save notes 

Enabled users to congregate notes together in one place and to reference them that way

The official specifications were to create something using AWS Lambda, DynamoDB and Amplify as the backend, and ReactJS in the frontend. This specification also mentioned the requirement to create a chrome extension to pair with a web app to allow for the congregation of the user's notes.

Essentially, we were told in full to design, develop and pitch a note-taking app all in the matter of 

😨 a task that sounded impossible at that time (remember we're all students here).

Straight after the initial meeting where our fates for the next two weeks were decided, we immediately got to work designing both the identity of our brand and the architecture of the entire ecosystem. Having been reluctantly positioned as the leader, I sought out to begin immediate development of the backend to enable our team to learn to use React as fast as possible and begin development immediately. In the meantime, alongside learning React, the team was tasked with designing all aspects of the app including the chrome extension.

Within 24 hours after the completion of our first meeting, I had successfully implemented the first iteration of our backend and released the development version of said API to the world affectionately called the 'Highlight API', a nod to the name of the task (also because we didn't have a name for our app yet). 

Alongside this development, the rest of the team was busy working on developing the face of the brand, as well as learning React (an absolutely monumental task considering we only had 2 weeks to learn and develop). 

The brand itself went through many iterations with us finally stumbling on the final version of our brand. We decided to go down the path of the Bee, and the idea of "bringing pollen back to the hive" a metaphoric nod to the ability of our app to allow people to bring notes back to the web app 'hive' using the extension as their 'wings'. It is also during this time that we decided on the first (but not final) name of our app Bee-It 

(If you can find any remnants of this branding, please let me know so I can fix it right away)

. Though this name was later changed to the name you know now as Scribee because the awesome domain name 

It was also during this early period that we created our first early (but rough) prototypes for the Scribee landing page, as well as the app. Though these prototypes continued to be developed as the days went by, and we approached the days before we had to pitch our solution back to those who gave us the problem.

At the end of this early point, we were getting into our groove, staying up late into the night, neglecting our studies and grinding for the completion of this application. We had high hopes and such hopes were going to be realised no matter what.

We had to get our product out there and function.

We had to get a beta completed, no matter how crazy it sounded.

Though so much had already been completed in the early phase of the project, there was still much to go. Many a-odd times whenever I'm completing a project, there is always this phase where all of the foundations have been laid, and development begins steaming along towards completion.

This is where we were at now. The train of software development is leaving the station! 🚂

For what felt like a quick start, became a quick end though. Remember this was a task that was planned for two weeks and to have a beta product by the end of all of this, leads to something akin to an impossible task. But somehow, we pulled through the grind. Over 4000 lines of code were written, constant re-designs of the smallest icons, staying up until 5 AM deciding on the font (we chose 

after creating a tier list of fonts) all combined to allow us to finish the first beta iteration (for the most part anyway).

Though we had a working product to pitch, the damage to our professionalist approach had been done. The code was a spaghetti mess with very little error checking, the Figma had devolved to a cluster of images splattered together with little care, all of us were sleep-deprived with sleep schedules all over the place, you get it.

But it had been completed, at least the theoretical beta product anyway. Cheers to the team for contributing what they could and learning how software development should work in a very limited amount of time. We pulled through the mud whilst our Accenture mentors gleaned at our struggle smugly, but what mattered was with the limited knowledge we had, we got the job done. Now came for the not so fun bit.

Now to be fair, we're developers, not salespeople, this isn't our cup of tea. But I think we got through it well. Spread across two days, the pitches comprised of two different events

These two high-pressure pitches were the main reason behind why we wanted to build a beta product so badly (avoid embarrassing ourselves), not to mention that a Managing Director of Accenture (Luke Higgins) was going to be there at the pitch to watch. 

We put it on ourselves to it's time to pull through. 

For the Accenture pitch, we formulated a much more extended dive into our software and the potential that the said product could bring to the market. We discovered that many of the competitors that were in a similar space were charging what seemed like arbitrary prices (some we charging 100+USD for the simple highlight and save feature!?!?!?!) and just rode that wave the entire time.

It was a 15-minute presentation that was delivered and included a live demo of the final product and its capability. Once the presentation was completed, we were asked a few questions about what we thought about the project, as well as what things we could do to increase the potential for our product.

I still have nightmares about the AWS SQS question that Luke Higgins gave me 👻.

That being said though, it went quite well and we persevered through the hardships to complete something we were proud of and wanted to show off.

This was possibly the most fun I had throughout the program. Being able to see what other groups had done and what they delivered as well as show off our own product!

Jason though had plans to WOW the entire audience and formulated something I can only describe as absolutely flabergasting.

A 2-minute pitch was set forward for us to deliver to an audience of almost 100 and Jason absolutely pulled through and delivered something of magnificent quality. 

It was absolutely enthralling to watch and the following hosting of our virtual showcase was awesome too! We had people from all over the industry visit and check out what it took to create something like Scribee. Individuals from companies like Capgemini, Deloitte, Suncorp, Canva and so many more visited our stand and tried out our product!

We even created a collaboration with the other group working with Accenture to present our products simultaneously!

The night ended with a poll on what booth was the most favoured and although we didn't win, we came damn close to doing so. Though the ending was bittersweet as it named the end to a program that I both learned alot in, and enjoyed being a part of. It is an event that I still remember clearly now, almost 4 weeks after the end of the program (as of writing).

The project still lives on and is somewhat frequently updated. Since the time of the program's ending, the project has been converted into Typescript and now uses redux for its state management, making it blazingly fast. It has also been made fully responsive so you can use the web app on your phone, anywhere, anytime (so long as you've got internet).

This entire project has been extremely fun and has opened the door to many new skills, connections and opportunities that lie ahead. There has been rarely a case where I've been able to fully exercise my skill set and work within a team to complete something under such a time crunch and I'll always be able to reflect upon this time as a good place in my career. 

Thanks for coming all this way to read all that I had to say about the entire Scribee journey. If you're still interested you can try out the web app and extension all located 

The journey to finding a better way to manage how you work.

Scribee

Yes, I know. You probably had to travel far and wide and stalk me on a variety of platforms but you ended up here! 

If you don't know already, I'm John, a current third year at UNSW studying Computer Science and a hopeful (but exhausted) software developer. This place that you have stumbled upon is my own little place on the internet to talk about things I find interesting (or to rant about stuff I find less so) so I hope you come along for the ride :).

I've been meaning to create something like this for a very long time now, probably ever since I started studying computer science almost 3 years ago. I've always had been curious about how people and companies can get their own blogs and content up and running and let them be updated live.

And so, after a long time of acquiring skills and waiting for enough free time I decided to create it. I had wanted to steer away from using WordPress and so sanity.io was the best pick after I decided to finally start it!

This entire website was made based on the provided 

 and is something that I will continue to make better.

 alongside the provided PostCSS that will eventually be phased out. All of the content is managed via 

 based system. This has all been packaged up into one repository somewhere located on GitHub and deployed via 

(my new favourite way to personal apps). The comments themselves are handled separately via 

Some features that I've also enabled for the blog that wasn't available from the get-go were stuff like 

g, code and youtube embedded videos (last two below).

There's a lot that I plan to use this site for, from my projects and technical interests, all the way to cooking up new recipes in the Kitchen. Hopefully, you can stay interested enough in my content and follow along in my journey through life.

An explanation as to why this exists on the interwebs.

Hello world!

My own little place to talk on the internet.

Welcome to my humble abode 🏠