Starting off the class day one I knew we where going to be building a chat app and I was excited. My mind already working on what I want it to be and it to look like, the time finally came! We started our apps. The fist day we had some live code going on to help us with the build of our project. It was at first helpful but the way I work I had to go experiment with the first bit of new knowledge I had gotten and that brought me behind. Not to mention the fact I don’t have internet at home so I am switching between thirty different tabs of helpful webpages I had saved during school.
This all started to make me go slightly crazy. Thats mostly my fault for going crazy with how the app looked instead of worked. I tried putting so many extras into my project before I even had the basis. The next live code classes we had were now beyond my knowledge base and I had no idea what was going on. I deiced to start from scratch about seven times, all from one simple error that was messing everything up. No exaggeration on the seven restarts. Being the anxiety in me I didn’t really ask for help at the time. Which I did in the end but at the time I should have. The fact that we had a massive storm helped give me more time to work on my chat app. But even so some of that time was spent helping some family in dire need.
Another week rolls in and the time is counting down. I’ve been broken down by code… I finally ask for help after trying as much as I could on my own. I get some things done and learn some new tricks. Presentation day comes along and I feel more comfortable talking amongst the class. I felt as if I got the presenting thing down a little more. Work can be done as I was told. But none the less Im glad its over with. I thought it was going to be easy at first and I realized it could of been but I made it allot harder. But I now have the knowledge to repeat everything I have done in the few weeks we had to do this to do this in a day. I feel more confident going on with future projects and I leave you with some tips to help you as well.
- Don’t get crazy with style until you have everything else you need done.
- Plan it out on paper first. Yes this actually really helped me!
- Don’t set your sights too high. Don’t try to create something beyond your current capabilities.
- Ask for help!!!
For the past month at UIT we’ve been assigned to create an instant messaging web chat application. We started off brainstorming ideas for what features that our chat app would have and went over specific requirements needed for the chat app like: two third-party sign in providers (sign in with Facebook, Twitter, Github), mobile view responsive design, and of course, either instant chat messaging or direct messaging.
At the beginning, I wasn’t sure what theme my app should have. I like playing video games so I thought I could find a way for the chat app to be themed around the video games my friends and I play. I eventually chose to have different video game titles to be chat room channels and to also have a “news” portion of the app where it would show the newest gaming news to promote discussion within the app and also inform gamers who are too busy to be constantly checking Twitter and Reddit for gaming news.
As I worked on the chat app, I received a lot of help from the mentors, Eric Lortie and Rob Myers. The week of the deadline, I planned on coming into UIT to work on the app more with both Eric and Rob on the extra days where there was no class, but then it flooded in Cape Breton. Everywhere was wet, some roads were even closed. My family was nervous that we might return home to a flooded basement however luckily our house was undamaged by the water. After the water on the roads cleared, I planned on coming back to UIT to catch up on some missed time, due to floods of course, and to finish up my chat app. However, the same day I came back to UIT I caught a bad cold which kept me from going to UIT for extra help. Over the weekend I did try to work on it remotely with the help of Eric through Slack, but of course working while very sick isn’t very productive. So add sickness, a runny nose, a cup of “you have to meet this deadline” anxiety and you got a recipe for really horrible feelings. So I have to say the relief of seeing that the deadline was extended was, well simply put, relaxing.
So in the end, I learned that you should always be prepared for the worst as a flood and sickness can unexpectedly happen at any time. The process of making app was challenging but still quite manageable with the help of the mentors. For tips for future UIT students all I can say is that if you encountered a problem you’re definitely not the first person to encounter it and any issues that leave you scratching your head without a clue, the mentors can always help.
Finally, I did get the app fully finished by presentation time. I would still consider it a work in progress but the main features are there. You can view the app here:
Originally I wanted to make a chat that sends obfuscated messages based on a keyword or phrase in a similar manner to the Enigma machine. But after some research I realized that at this point in time a function of that magnitude is much too advanced for me. So instead I opted for messages sent and stored under a keyword or phrase that can only be retrieved by a user who knows said keyword or phrase. Messages are sent completely anonymously stored under the encryption key and aren’t tied to users at all.
The user can change their nickname various times since this chat is all about anonymity and privacy. Realizing that obfuscating messages was too complicated for me quickly taught me that I must do research prior to choosing what I plan to code. Also time management is very important, if you assume that a certain time frame will be enough you’re wrong and always will be. So many little issues will always occur and it’s near impossible to predict how long something will take to complete in a fully functioning manner.
Something else to note is you want to be consistent in naming your variables because it will save you loads of time from double checking what they were over and over again, something I learned the hard way…. None the less creating this chat app was a bunch of fun!
The satisfaction at the end of making it was so rewarding and totally worth the time and effort put into this project. Though at times you’ll fell patience running thin when things don’t work and you may feel like you want to break stuff! Don’t, just take a break and finish it afterwards because the end result is worth it.
Roughly in order of importance.
Lesson One – Don’t underestimate how long it will take
A chat app. Sounds simple, doesn’t it? When the project was announced a few weeks ago I figured I’d need about 20 hours. Five or so hours week one, maybe five to ten week two, ramping up to a big ten hour push in the waning days to git ‘er done. This was my first rookie mistake. This past Saturday, after probably 40 hours of clacking away, with the original deadline about 36 hours away and needing at least 20 hours to (possibly) get my project to some incremental but functioning level of completion, gave rise to a significant amount of reflection upon the process and how I got there. The following lessons will reflect those musings.
Lesson Two – Get out of the gate with a strong start
Working with a greater sense of urgency in the initial days can never hurt. It’s not as though I procrastinated, but had I been able to put in 30 hours a week starting week one I either would have been able to finish with time to spare or been able to add more features and make my app prettier.
Lesson Three – Communicating explicitly with our student success coaches is vital
We were lucky to get an extension of a few days, which was a welcome relief and contributed greatly to my happiness. It also made this a better educational experience. When the last minute extension was granted the comment was made that our coaches were caught off guard that we were struggling to finish. I try to be explicit in my communicating, especially as I try to balance the needs and attention that my young family requires, but in this case I probably could have said more. Writing this chat app was a valuable experience. Finishing it in a big panic would have deprived me of some valuable learning opportunities and would have been a disappointing conclusion to a lot of hard work.
Lesson Four – There are no shortcuts in coding
At least I don’t know any! If you’re scrambling to finish a speech or write a paper you can always do a cruddy job and pound it out. There’s always features that can be dropped, and styling shortcuts, but if code doesn’t work… it doesn’t work. And that’s not good!
Lesson Four – Pitches take work too (and it’s a process)
Concurrent with this, our first big project, was also our first real “pitch”. I am not afraid to stand in front of a crowd but there is a difference between not being nervous and not looking nervous. Also up for refinement is the content of our presentation. I know that making a good pitch takes work but I have a new appreciation for how creating a good pitch is a process that takes feedback and refinement. Giving presentations is something we’ll be doing all year and there are lots of resources and mentors to help and give us back whatever we put into it. I hope to be a whiz by year end.
Lesson Five – Plan to finish with time for testing
I should consider the “due date” to be not the actual due date, but at least 24 hours earlier. Leave enough time for thoroughly testing the functionality forwards, backwards, from every approach and in every platform.
Lesson Six – First focus on the deliverables
I think I did an okay job focusing on the deliverables but I saw examples in other projects where non-core components consumed too much time and left the creators scrambling to finish the assigned components.
Lesson Seven – Design for phones first
Mike made a great comment that I will try to remember: plan your design and layout to suit viewing on phones first, then work out towards desktop views. It’s easier to design for desktop so design a phone layout first and the desktop will follow easier than trying to work in the other direction.
Lesson Eight – I don’t like NoSQL
I like data. I don’t like data in NoSQL databases. I thought the slicing and dicing of the statistics I was going to be generating from my chat app was going to be fun but it was no fun at all working in a relational database that I couldn’t intuitively wrap my head around.
Lots of important lessons, which I guess is a great sign in an educational setting! I look forward to not having to learn these same lessons again.
As a final note, I was sincerely impressed by the diversity and quality of the apps my classmates created. There is a great deal of talent and creativity in this room. Also a huge thanks to Rob and Eric, without whose guidance and instruction this app would not have been possible.
The class has been working away at some pretty interesting projects over the past few weeks. The goal of our project was to create a chat application, with two unique features, chosen by each of us individually. It was originally due on Friday, the 14th of October. I had a great idea for my project, and was sure I could get it done within a reasonable amount of time. Or so I thought.
Firstly, I’ll tell you my idea. I set out to create a way for Netflix users to watch it together, while chatting at the same time. As I looked further into the idea I started digging myself into a deeper hole. I was losing sight of what I had originally set out to accomplish. It was a nightmare, but I was determined to turn my idea into a real thing. Big mistake.
It turns out, once you figure out that an idea you have is unrealistic (especially one with a due date), you really should take a step back, and just ask yourself if it’s truly worth it. I ended up feeling overwhelmed and thus unable to concentrate on actually getting a project done at all. And so, after accepting the fact that my idea was just infeasible for this project, I decided to pivot.
I felt a bit more at ease after I changed my project idea to target YouTube, rather than Netflix. Not only there were more resources on the subject, but YouTube is actually open to allowing developers access to their API. The only problem was that it may have already cost me too much time. Even though I was in the right direction now, the time frame I had held me back from doing this project in a way that I’d be proud of.
And then suddenly, floods. The city now looked more like a lake. People had no power, meaning they couldn’t work on their chat apps. Naturally, the due date had to be moved from Friday to the following Monday, the 17th. This gave me more time to work on my project and prepare during the weekend. The functionality was all there, but something just felt wrong. When you pour your heart into a project, you’re proud of your work. But all I felt was a strange disconnection. It took me back to how I felt after finishing projects in middle school. I knew that I hadn’t put my all into it, and its current state, is truly unfinished.
And then I saw a glimmer of light through the trees. The project had been moved to the next Friday, the 21st! It gave me the chance to turn my project from something I was assigned to create, to something I wanted to use. I still had to do my original pitch on the 17th, but it was more of a practice run. It let me know what I needed to work on for Friday, and that’s how it worked out. After doing my pitch on Monday, I realised there was a lot I wanted to work on. The practice run helped me gain confidence for Friday’s presentation.
Over the course of the week, I began checking items off of my list of features I wanted to implement. I wouldn’t have been able to get many of them done if it weren’t for the second due date change. This whole experience taught me a few things to keep in mind for the long run. One of the more important ones being to not bite off more than I can chew. Just because something sounds like a great project does not mean it can be realistically created, in a relatively short time span. Another thing would be to trust my gut telling me that I could have done a better job on the first time around.
Starting three weeks ago we were tasked with making a chat application. Everyone was to pick some unique features they could throw in to make it special but the core was the same. The apps needed to have real time chat (Direct or Chat Room style messages), and we were using databases, this time through firebase.
Being a big Pen and Paper gamer (i.e Dungeons and Dragons, Pathfinder, etc) with lots of friends not from Sydney I thought I would make something that could be used as an aid for playing those games. There is already a really good website called Roll20 that I like to use, but most people I know have trouble using the software, so it ends up complicating things rather then make it easier to play the game.
The two features I choose were:
- A grid you could draw on, which is important to playing P&P games
- and the ability to roll dice, which is completely mandatory for playing those game
The Project was impossible starting off. I spent the whole first week trying to make a wireframe and flesh out all the HTML. I did everything I knew to try and style the page, and as far as I could tell it should have been working. Until lastly I set the hight of the body element. Suddenly all my styling came through and everything worked.
I stumbled through several of these problems. Where lots of time went into trying to find the problem with the code, only to find out it was somewhere else that a minor thing was stopped progress. For example I couldn’t make dropdown menus work for quite a while, and spent hours checking and rechecking the thinking I did it wrong. But it turned out I just wasn’t using the correct Bootstrap package.
After those types of problems stopped happening, I got into the nitty-gritty with Firebase. That was where my real difficulties began. None of the code was overly complex, but the thought that went behind trying to make all the interactions with the server work was hard for me to think through.
Eventually, though help from Rob and Eric I was able to get all the functionality of my site worked out and have had a lot of fun playing around with it while it’s working.
Important take aways from this assignment for me include:
- Don’t forget to review all your scripts and sources for things like Bootstrap, JS, JQuery, etc.
- FireBase has two reference websites, one of them if totally wrong and not helpful.
When In Doubt, Google Out.
That seems to be the theme for not only the course but life now a days. If you don’t know something then, hey just Google it. I’ve been saying to Google for years, but I don’t know if it’s my old age that has diminished my Googliness, or I’ve just reached a Google curve.
I used to suggest to clients and customers all the time to just Google this exact problem and how to search it. Well this last 3 or so weeks, I’ve forgotten my Google formula; I don’t know if it’s just perennially I saw it kinda as cheating a problem in academics, or I just couldn’t get it. But just Google the exact problem you’re having makes life and studies and coding a lot easier. Asking ‘hey Google, what command in Terminal do I use to create a new directory? MkdLR, oh thanks Google!
Besides getting my Googliness back on point, we’ve had an intricate week on fire base. Using fire base as a data directory and integrating it into our JS. It’s been another curve, but absolutely fun! I’m currently in the transition of polishing my chat app, and doing the leg work -with a few fine tunings. The biggest obstacle for me will be getting the info for the app and having the users be able to use it. I’ve already have my authentication completed and like I said the rest is just polish and leg work!
We also had another great speaker, Peter Moreira, very knowledgable guy. He knew what he was talking about and a lot has gone hand in hand with what Matt has taught us so far.
All in all, another great week here at U.I.T. Can’t wait to eat my turkey dinner and get back into class to tackle these chat apps!!