• Skip to main content

DigitalLabs@MMU

Digital enterprise at Manchester Metropolitan University

  • Home
  • About
    • Digital Labs Team
  • What We Do
    • Teaching
    • Services
    • Products
      • Appatella
    • Portfolio
    • Tutorials
  • Latest
    • General
    • Jobs Board
    • Our Team
    • Products
    • Software Development Services
    • Digital Labs Portfolio
    • Teaching
    • Live Projects
  • Jobs At DigitalLabs
  • Contact
You are here: Home / Latest

Latest

October 30, 2018 By Laurie_DigitalLabs@MMU

Live Projects – 2018

Alice DigitalLabs@MMU

Time to kick off our Live Projects 2018!

This year, we’re looking after 20 teams of 4 students as they embark on a 6 month MVP project, culminating in a showcase event, at the end of March, 2019.

Good Luck, Teams!

(If you need anything, just call Alice)

Filed Under: General, Live Projects, Teaching Tagged With: audience:Student, Live Projects

October 3, 2018 By Zebra

What’s Cordova?

Codova Logo

Cordova is an open-source system for making cross-platform mobile applications in JavaScript, HTML and CSS. It effectively wraps ‘web apps’ as publishable applications, which are functionally equivalent to native applications, as far as users are concerned, but has the development benefit of not requiring a different codebase for each platform that is to be published to.

Cordova is used as a terminal-based application, itself written in JavaScript and running on Node.js. Plugins for Cordova are available and are installable through NPM, the Node Package Manager, and provide a huge range of extended functionality (often implemented with native code and bridged through the Cordova layer transparently).

Originally developed as ‘Phonegap’ by Adobe, it is now managed by the Apache Software Foundation.

Filed Under: General, Nanoposts Tagged With: nanopost

September 19, 2018 By Digital Labs Admin

Professional Development Unit Live Projects

DigitalLabs and Professional Development

Hi there! We’re DigitalLabs@MMU –

If you’re a 2nd Year Student involved with any of the computing courses, then chances are you’ll be doing a Professional Development module. That’s where you’ll meet us. We’ll be hosting a few of your labs, and running some of your Live Projects.

[Read more…] about Professional Development Unit Live Projects

Filed Under: Live Projects, Teaching

September 17, 2018 By Digital Labs Admin

Yusof’s Final Week Interview

Week 12 Interview

It’s Freshers week here at Manchester Met and summer is officially over, which means that our amazing intern Yusof has reached the end of his time with the DigitalLabs Team. The project is finished and the software is ready to be handed over to the client. Before he left to start his final year as a Computer Science student, I spent some time with Yusof asking him about his time as a member of our team.

What have you enjoyed most about your time with the DigitalLabs Team?
I’ve always enjoyed programming, so programming every day five days a week has been really really fulfilling. Really awesome. Going through the whole process. Going from wireframing a system, to developing it and then this week finishing it off has been a really fulfilling process. It’s not something you really do in university. I think that’s been the most enjoyable. Also being part of a team and going to work every day. It adds more meaning to your life than just uni and going in and out. I think that’s been one of the best things.

Now that you’re starting your final year, what advice would you give to first and second year computer science undergrads?
That’s an interesting one. It’s interesting that I never got advice from anyone. I think I was the only one in my whole year that chose computer science as a degree at university. I think the biggest thing is don’t just rely on learning from university. University is going to teach you, so say you learn Java in your first year, go out and do extra stuff and try and learn more than what’s given. Even if you don’t know why you’re going to be using that, you’d be surprised how learning one thing will apply to something completely different. I think for me I enjoyed JavaScript as a programming language so I randomly did that as a hobby and I never realised that as a summer intern that I’d be doing JavaScript as well. Having a solid base of JavaScript helped me perform in the three months of the summer internship. So I would say that my first piece of advice is to carry on learning stuff, even if it’s just reading articles or reading more stuff. I think that’s always an extra thing.
Other advice – Just try to enjoy it. I think that there’s parts of computer science that you’re not going to like and that are going to be really boring and there’s going to be parts that you are going to like and it’s getting that balance right. Enjoy the stuff that you like and the bits that you don’t like, just deal with them and make sure that you can perform them both. I think they’re the two things I’d say.

If you spoke to other second year students, would you recommend doing a paid internship or do you think they should be partying and enjoying their summer?
It would be nice to enjoy your summer and party, but I think internship 100%. The interesting thing is that the university and a lot of other places push doing a whole year internship, which is a great thing as well, but if you don’t want to do a whole academic year you can then just do a summer internship and still do three months of solid work, rather than take nine months. Summer internships are the great middle ground of not wanting to do a year but still wanting to do something that’s more than just two weeks of work experience, which doesn’t really mean much. A criticism is that three months is not a lot compared to nine months but then you’d be surprised how much you can fit in five days a week. If you put in the work in three months, then you’re going to get a lot out of it. I think 100% everyone should do a summer internship.

Was it helpful that the internship with DigitalLabs was paid?
Yes. I think that just within the computer science / software engineering field having a none paid internship is rare. Having it paid makes you take it a little more seriously. It almost becomes a real job, something that is real. Its nice to get paid. Comparing to mates who don’t work and are having fun on their summer, but then you know that you’re getting paid for what you’re doing so there is that and if in your third year you live by yourself you’ve got extra cash that can be spent on stuff.

Did you find it useful having to go through the recruitment process for the job in DigitalLabs?
Yes. Interestingly when I first applied, I didn’t realise that there was going to be an interview. I thought it was going to be just apply with your CV and you either get it or not, so I was surprised initally that there was going to be an interview, but I was like OK that’s a regular thing. That was like my second or third interview in my whole life. It’s not something I do regularly. I think 100% it was useful. I think interviews are just a thing that the more you do the better you get at it, you just get used to it. I think it’s been as useful as doing the internship. The thing about applying for internships and applying for jobs, you just do the interview and you either get it or you don’t and you just try to improve from that last interview. The recruitment was exactly like applying for a real job, I think that was the biggest thing. You’ve got to get a CV, you have to send a cover letter, then it was an interview then you either got the job or you didn’t. It was also quite an interesting interview. It wasn’t necessarily the easiest interview, there were a lot of questions. I wasn’t expecting any technical questions, but there was and that’s something you have to be prepared for. It’s a technical job, so you’ve got to be prepared for technicality. People need to know that you can code and that’s the biggest thing.

Do you think that your time with DigitalLabs is going to be helpful to you when you leave uni and start a full time job?
Yes 100%. Step one just having something on your CV that’s legitimate experience rather than a random or university project. It’s saying that I’ve actually worked with a real company. Interestingly I think that the bigest benefit will be the social aspect. Actually working in a small team with everyone trying to work to one idea, one project, it’s different than working on a university project. It’s a whole different dynamic between those. Working in a small company and hitting deadlines and having the pressure of clients. Obviously your programming skills get better, mine have got much better over those three months, but you can learn that, you can teach that, but working as a team and hitting deadlines is much harder to teach and I think that’s what you really learn from that and take away.

What did you find were the challenges whilst you’ve been with us – if anything?
Other systems on the development project. This one I think technically had three or four new technologies that I had to learn in seven weeks development so that from day one has been a bit of a challenge and you’ve got to stay on top of things You can’t spend a week learning something, it’s not going to work.

I think that when you look at going to university you go in for three or four hours and then you’re done and you’re not even going in five days a week. Just working at something five days a week , waking up at 7 O’clock in the morning and going into work and then staying for seven or eight hours a day, just that has been challenging in itself. A straight three months. You’re not going to get a break, it’s just solid work. The biggest challenge is probably just that. Real life work experience.

Did working with DigitalLabs give you any insight into working as part of a small team?
Yes. The interesting thing is that obviously in computer science first year and second year, you have group projects with people, who are maybe really unreliable or really just don’t care. There’s always different types of people, but when you’re working at a job, everyone is caring and everyone is putting in their effort and working towards the same goal, so there’s a whole completely different dynamic, a completely different way of thinking and working wth a group.

Did you learn anything new or any new skills during your time with DigitalLabs other than the one’s you’ve learnt as part of your degree course?
New technical skills, like stuff on full on authentication to creating REST APIs, two big things that you never actually do in Computer Science. They teach you how to think like that and then you just learn it yourself. I think also being able to communicate what problems you’ve had and what issues you are having with your code . When Dave and I were having issues, I had to communicate 200 line pieces of code within three minutes to explain what the problem was and how to solve it. If you had an issue that was going to take a week, how were you going to talk to the other team members and make sure that you break that down and then you can solve it in half a week. I think that’s a big thing whereas in university you have time on your side, so you don’t really have those issues.

How did you feel about publishing your weekly diary on the DigitalLabs website?
The diary was interesting. It’s an interesting thing because it’s not a normal thing to do or have as part of a summer internship and it was quite interesting and quite enjoyable actually in some ways.

One thing is that now when you start looking back at the diary, it’s a lot more fulfilling than when you’re actually there, because you start seeing all the things you’ve written about and what you’ve done and no doubt as time goes on you’re going to look back on it and get more enjoyment out of it. The best thing about the diary was a way for you to look at what you’ve done in the past week, or two weeks and see what you’ve learnt and what you felt. In many ways it’s a really useful thing and maybe it’s something that should be more common in computer science. You think of computer science internships as just programming and that’s it, but it’s a lot more. It’s a lot more social, you learn a lot from that.

What was it like working in a team where you were a lot younger than everyone else
I think that’s quite interesting. When I first joined I knew that I was going to be the youngest and I was completely prepared for the idea of just working, going in and out and quite quickly it was quite enjoyable, quite nice – all of us went to the pub, all of us did things after work even though there was quite a large age gap. Everyone’s old enough to be my father but you learn so much more from that I think, you’ve literally got 30 – 40 years of experience, probably more totalled up and sometimes just listening rather than always voicing your opinion can be so much more useful. You hear other people say what they’ve done and how people have progressed from different jobs.

This will be the first time that I’ve worked with people who are considerably older so it’s actually been a lot more enjoyable than I expected and I think that’s really cool. The most interesting thing is that you start realising that we have all these different common grounds and maybe different opinions about them. You find common things even though there is an age gap. There’s always going to be different ages when you’re working, there always is, you get used to it and you get past, you just find those common grounds which I think is really quite interesting.

What was it like having a client to work with?
Computer science is one of those degrees where you almost don’t want to work with clients, you choose it so that you only work with the most technical people and everyone understands what you’re talking about. Some computer science jobs are like that and you don’t have to work with clients. Working with clients can be quite a challenging thing, because all of a sudden you’ve got to completely change the way you talk and approach things, you can’t talk technically, there’s no point, it’s not going to work. At the same time it’s incredibly enjoyable. Computer science can be one of those things where you never really show people what you’ve done because people aren’t going to understand how good this algorithm is, but with clients you can literally every day see the progression. You can see how they like stuff and how they dislike stuff, even though it might be getting a little bit annoying if they can’t see you changing stuff, actually that’s what keeps it enjoyable. You have the feedback loop, the constant changes and that constant improvement at the same time. I think it’s like chaotic and order, which is really interesting and I really enjoyed that.

Has it been good having someone from the research team coming in and seeing you most days?
Yes. I didn’t think that I would enjoy it as much as I did. It has been good. I forget how many times you see the client, it was nearly every day for about three months so you start to build this really interesting relationship. it’s been one of the most rewarding things. now you’re seeing how they could use it and the ways they’re thinking that they could use it you know that you’ve created a product tht’s helped someone. I think that’s the biggest thing, the most enjoyable part of it.

What do you think will be your favorite memory of working with DigitalLabs?
That’s quite a hard one. It’s quite hard to pinpoint that to a specific moment. It might be the first time that the actual system was working as one and I remember Laurie and I looked at it and we were messing about with it, playing with it and all of the sudden we started to see how this could be used and what it could be used for and there was this moment, where we started to realise that we could apply the system to anything and anyone who has time series data capture graphing. I think that was my most fulfilling moment at the time. You went from first week of wireframing, designing and this is what the system could be and you don’t know where it’s going to go to, all of a sudden we’ve got something now. I think we both realised at that point that we both had something solid and that was a really really enjoyable point.

Was there anything about working at DigitalLabs that you didn’t expect?
I think how in-depth and fulfilling it was to be part of a team and work every day. I’ve obviously worked at random jobs whilst at uni and had summer jobs but when you work on something you really enjoy and you’re really enjoying every day all of a sudden going to work and waking up becomes quite enjoyable, quite a nice thing. It’s really quite fulfilling and meaningful. I think that’s been the most unexpected thing, even after three months it still doesn’t feel like a job. It still feels like its a fun place and you forget that you’re still doing something quite real. I think that’s been the most fulfilling thing. I expected the high of getting a summer internship to depreciate after two months but it hasn’t it’s stayed up and got even better. I think that’s the biggest thing. I remember getting my first job at Tesco when I was younger, it was awesome to get a job and start earning but I think it was within the first month and I was –  why did I get a job? I have to wake up in the morning every day, no one else is working and you’re stuck at 6 o’clock in the morning at Tesco so I was expecting a similar process and it really wasn’t and I think that shows a lot about what I want to do in the future and what I want to be.

Is there anything else you’d like to add?
Don’t underestimate the value of a summer internship. I think people say that it’s only three months, but three months is actually a long period of time. Eight hours a day, five days a week, if you calculate it. All of a sudden it becomes a huge amount of time and it’s not just technical experience. I was comparing my programming skills from before the internship to now and they’ve just dramatically increased. I didn’t know anything about Angular.js which was building single page web apps and now I feel like I’m really confident in that, which is apparently quite a rare thing. Doing something the same, every day, five days a week, programming and working with a team, you realise how much time that adds up to and how quickly you can start getting stuff done. I think that’s been the most fulfilling thing. I almost forget that this is the last week and it’s quite a sad thing.

Another surprising thing is that I didn’t fully realise how small the team was, but at the same time how much you can do with four people. You realise the value of one person. A lot of summer internships are very focused and you’re part of a massive team doing maybe one tiny thing, but on this summer internship I literally did everything. I went from wireframes, user stories and designing the thing to wrap up. I got basically a cross section of the whole development process, which is really quite a rare thing and very rewarding. Usually you just focus on maybe the back-end or the server or the front-end so I think having a cross section of everything made it really fulfilling.

In computer science we never do front-end and we never do design, colours or that stuff, we just focus on back-end usually and all of a sudden I’ve got an understanding of UI design from Dave who has a lot of background in UI and obviously now I’m looking at things differently. Tiny things like that, which you know that you’re going to use in future projects or personal projects and I think that’s one of the most interesting things.

Filed Under: Our Team, Yusof's Diary

September 7, 2018 By Yusof_DigitalLabs

Eleventh Week at DigitalLabs

Yusof Week 11

Second Week Testing

This week focused on finishing the last couple of features and testing. Development is coming to an end thus some of the extra features have been moved to out of scope. Both the OneDrive login and import panel have been reworked, allowing multiple OneDrive accounts to be used.

The Plan Will Work?

Before starting development the largest concern was the relatively short amount of development time, 6 weeks, for such a large project. Having only 6 weeks forced us into an “only core features” corner, removing any unessential features, leaving us with the purest form of the system. Using Trello each feature was planned out within the 6 weeks following a simple but effective template.

Each week of development time will correspond to one sprint, each sprint is a Trello list. Each sprint list will have a corresponding Pending and Done list, indicating which features are currently in development or completed respectively. Additionally, the Out of Scope list holds all the features which have chosen to be unessential, in total the Trello board contains 24 lists. Using Scrum for Trello, a Trello extension, I estimated the number of hours each feature would take, once a feature was completed I would document the actual number of hours the feature took. In the end, the Trello board will provide a full diary of development.

According to the plan the development time would take an estimated 160 hours or 4 and 1/2 weeks leaving approximately 2 weeks of extra development time. Breaking down the 160 hours, I predicted the largest task, Search Pages and View Page, would take a total of 79 hours on the other hand Authentication and Search Page UI, the smallest tasks would take a total of 17 hours. The two weeks of extra development time would be planned out closer to the time.

I love it when a plan comes together, well this plan didn’t, not at all. A combination of the dreaded unknown unknowns and the popping of extra features pushed back development time by a number of weeks, sprint 8 was the predicted finishing time the actual finishing time was roughly, sprint 10. The first two weeks of development, sprint 4 and 5, focused on the backend implementing each endpoint and database queries. In total the sprint 4 and 5 took me an actual of 75 hours, 17 hours quicker than the predicted number of hours. Development time for the backend was quick due to earlier preparation, the weeks leading up to development time I had thoroughly investigated each API and the authentication flow minimizing the chance of an unknown, only minimizing, the inevitable did happen. On sprint 5 an ECONNECTRESTET error occurred tagging 3 extra hours of development time, you can read here how I fixed the issue.

I was hopeful for future sprints, continuing with the same rate of progress I would finish the whole project even earlier, I would soon learn the harsh lessons of software development. Akin to earlier sprints, the start of sprint 6 development was relatively smooth completely finishing the import panel, implementing the search on the other hand was a whole different fight. The first major unknown occured, a jsTag bug, followed by the back button breaking totalling in 13 hours fixing bugs rather than development. In total sprint 6 took 41 hours instead of the predicted 21. A similar story persisted throughout the sprints 7 to 10 on average development time took 15 hours longer than expected. My hard-fought software development tale is not a unique one it is the nature of the beast, development is incredibly hard to predict, the most common reason software fails, its important to make the plan flexible reducing the chances of a break.

In addition to unknown bugs, minor changes and features were added between sprints 9 and 10. When a new feature is added to the plan I first labeled it as an extra feature, secondly using scrum I predicted how long development time will take. If an extra feature could not be completed it was moved to the Out of Scope list clearly showing to the developers and client which features are not within the plan. Overall a total of 12 features were added ranging from UI changes, dynamic axis labels, to new API endpoints, file storage logout endpoint.

Release and Issues

Every day, with the exception of Monday, a new version of the system has been released allowing both developers and clients to see the progress being made each day. Last week Version 0.1 of the system was released by the end of this week version 0.1.5 will be released.

With each new release comes a corresponding release note, detailing the changes made and bug fixes. For example version 0.1.1 release note, read here, outlines one major change, annotation operations are persistent, and three bug fixes. Each bug fix links to a closed GitHub issue which provides more issue detail and the fix.

Mentioned last week with the release of Version 0.1, 22 issues were found this week an additional 15 were added, soon the Github issues list will be too unruly to navigate. To combat the unruly nature of the issues list I first ensured each issue followed a similar structure. Each issue contains three parts:

  • The current behavior, detailing the issues behavior,

  • The expected behavior, how the system should act

  • How to reproduce the current behavior, the steps needed to reproduce the issue.

Having a consistent structure ensures each issue contains all the necessary information, aiding the developer to efficiently fix an issue.

Furthermore, a number of Github Issues labels were used to quickly describe the issue as well as group similar issue types together. When a new issue is added it is first tagged with the appropriate labels. If a new label is needed, a new label is added either by the client or the developer. Similar to the issues list if too many labels are created using them effectively can easily become unruly.

For the Github Issues list, the labels fall into three main categories:

  • Type of Issue

  • Main Version

  • Location of Issue

The type of Issue falls into three subcategories, bug coloured red and the rest shades of blue:

  • Bug, the features current behaviour is not what is expected

  • Enhancement, a whole new feature to the Single Page Web Application (SPA)

  • UI-Change, a minor change to the SPA UI

The location of Issue falls into 3 three subcategories coloured shades of green:

  • Search Page, issue occurs on search page of the SPA

  • View Page, issue occurs on graph view of the SPA

  • Annotation Panel, issue occurs on annotation panel on the view page

  • SPA, issue occurs everywhere

A single issue is always tagged with a main version, type of issue and location but may be tagged with a number of subcategory labels. One example is the “Control Reminders“, this issue is tagged with a version number and location and two types Enhancement and UI-Change.

All the labels can be viewed here, take note of the number of issues.

In addition to adding issues, many issues were closed so far 10 issues have been closed, take a look here

Conclusion

This week the Issue list still seems to be growing everyday but all features have been completed. System releases will still continue next week as well as testing. Furthermore, as next week is my last week all documentation and handover will be complete.

Filed Under: Our Team, Yusof's Diary Tagged With: audience:Student, issues

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Interim pages omitted …
  • Go to page 10
  • Go to Next Page »
  • Home
  • Contact DigitalLabs@MMU
  • Digital Labs Team
  • Jobs Board
  • Privacy Policy
  • Twitter

Copyright 2018 - 2020