This week as I was looking for articles, there was one particular article that caught my eye almost immediately. It is called, “Artificial fly brain can tell who’s who” I knew that I had to write about this article. This article was posted in mid October (October 18th to be exact), so it is actually fairly recent.

This article talks about how researchers at the University of Guelph and the University of Toronto have built a neural network that almost perfectly matches that of a fruit fly’s visual system, and it can even tell the difference between other flies and even re-identify them. They obtained this by combining the expertise knowledge of the biology of the common fruit fly and machine learning to produce a biologically-based algorithm.

The article then talks more about the biology of the fruit fly, and talks more about the computer program in the following paragraph. The article then concludes by talking more about the future of neural networks and AI.

I throughly enjoyed this article, and I truly believe that it was well worth the read, and I encourage others to also find the time to read this article. The part that I found the most interesting was that using this neural-network-machine-learning-based program, this “artificial fly” was able to identify other flies with a score of .75 or about 75%. They tested this by recording the fly for two whole days and then testing the program on the third day to see if it was in fact able to identify it. They also tested just the algorithm without the fly biology constraints, and this scored a .85 and .83. This is only slightly better than the program which is very good results. They also went on to compare it to human fly biologists, and they only scored a .08. Lastly, on top of all of these comparisons, they included that random chance would only score a .05. This is unbelievable in my opinion. The fact that a computer program scored that much higher than a human is truly insane. I think that this research is a huge step in the right direction for AI. After reading this article, I am much more interested in AI, and plan to continue to research the topic more.

Article URL: https://www.sciencedaily.com/releases/2018/10/181025142010.htm

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

https://www.infoworld.com/article/3290253/application-development/6-usability-testing-methods-that-will-improve-your-software.html

A/B Testing

A/B testing is a type of testing where there are two different application designs, generally websites, that are tested over time. Data is collected on their performance with some sort of goal in mind such as product sales. If analytics show that one of the designs was better at achieving that goal then one is declared superior and is chosen as the design to go with. This can lead to even more A/B testing against other designs until the development team comes to a decision. The analytics for the test is often times done through third-party tools rather than an in-house solution. An A/B test can be as specific as you want, to the point where you only change a single small element between the two designs or they can be made completely different. It is often best to define a specific problem keeping you from your goal that you want to investigate such as users failing to complete a transaction. A/B testing is extremely clear-cut at providing measurement data for design decisions but can take a large amount of time to conduct the tests and produce the data.

Design Prototype Testing

Design prototype testing can be used to test a complete workflow in a wireframe or fully designed portion of a product before it goes into development. A UX/UI designer will create the prototype and the test will help fix usability issues before the project goes any further. It is important to define a budget for the project as well as the specific goal. Then you need to choose a prototyping tool such as Axure. Third, you will need to choose a measuring tool to gather analytics from the user such as Loop11. It is important that the development team is familiar with such tools to make the test worth the time and work investment put into the test.

Formative Usability Testing

Formative Usability Testing is a type of early-stage testing that focuses more on quality assurance. This test should occur before the first release of the developed product so that it can become the baseline for future tests. With formative usability testing the product will go through a beta test where groups perform the defined usability tests. Test cases are usually written down in order to inform the participants through specific goals in order to get meaningful results. Afterwards it is important to analyze the feedback and make revisions to the product before the official launch. This can be repeated in order to improve the product over time.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

This pattern also dealt with a very important aspect in our everyday activities as an apprentice. I will say feedback are necessary because they do not just correct me but they also guide me to explore new directions and track specific causes to my failure. Even though, we got positive and negative feedback, I  strongly believe if you are able to accept them regardless of what kind they are and do a thoroughly assessment of yourself, they can be useful to you. Sometime, you might believe yourself and try counter defends yourself by explaining as to why you did something to a criticism instead of accepting it as a feedback. Getting feedback that enable you to figure out what to do more or less is very important to your success. I have drawn a lot of ideas from this pattern that I think will go a long way to help me stay focus in the software development industry.

For instance, I will be very mindful of what could come of me if I am in the teams where my skills are above average or below average. I will be very careful not to think I am the best when encounter with such situation. I will also not down grade myself too much to the extent that it will destroy me because I am the less skill among the team I am working with; it will give me the opportunity to extend my tentacle and learn more to catch up with them should that be the situation.

I really like the ideas discussed in this pattern. Because, as a newcomer, I am bound to face some shocks regarding feedback I will receiver but with this pattern’s ideas in mind, I think these shocks could be turn into something useful that will help me assess myself. I wasn’t even aware of some of those techniques for obtaining feedback such as test driven development, Exams and certifications that have been discussed in this pattern until I read it. Before reading this pattern and if I haven’t come across it, I will just assume I didn’t meet the standard a company might want if I am not offered a job after attending an interview. I wouldn’t bother myself to do a follow up to know why and what I need to improve on. The ideas in this pattern are really going to help me in the future.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

This week, I will be writing a reflection on the “Reading List” pattern.  This pattern addresses developers who are proficient in their first language but feel that the amount of knowledge to be learned about the language is growing at a faster rate than they can acquire it.  I chose this pattern because I have been visiting book stores to shop for software development literature.  While I feel proficient in a language, I have yet to encounter this worry of an expanding knowledge-base that I’ll never fully acquire.  I do, however, plan to begin putting a reading list together as I continue preparing for my internship in the summer.  Regardless, Oshineye and Hoover provide sound advice on how to manage the books you plan to read and how to reflect on your past reading habits.

Their first piece of advice, ofcourse, it to create a list of the books you plan to read.  This is useful in that it allows you to plan out a kind of strategy that will allow you to learn incrementally and notice patterns, trends, and gaps.  As a side note, they also suggest that you make your reading list public to open the possibility of receiving suggestions for future reading while also allowing others to follow the same plan you did.  They recommend that you treat your reading list as a priority queue, as it will help you realize that some of the books on your list might actually not be worth reading.  To initially create your list, choose books that will broadly cover the area that you are studying, and then subsequently drill down on individual topics as you filter out the ones you find most important or interesting.  I found these tips helpful and will likely use them when I head to the bookstore soon.

They conclude the pattern by describing the kind of action you can take to begin implementing this pattern in your own life.  They recommend listing the books you are currently reading in a text file, and then progressively update the list as time goes on.  As long as you maintain the text file, you will be implementing the pattern.  I began my list today, with Clean Code and Apprenticeship Patterns being first and second in the queue.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

In this apprenticeship pattern, the authors present a context in which developing software professionals are “spending a lot of time exploring blind alleys.” They then describe the problem by saying that the software apprentice is “walking along a path” but having trouble being prepared for “what’s around the corner.” In other words, they are describing the difficult task all software apprentices face when trying to learn new skills and master their craft. The authors then go on to remind the reader that every software developer who is considered to be a “master” in the field, has walked the same path and knows exactly what that path entails.

For the solution to this problem, the authors suggest that software apprentices “seek out” those that are considered to be masters who are further along on “the long road” and attempt to learn from them. However, this suggestion comes with some warnings. They point out that as an apprentice it may be more difficult to spot the true master craftsman in the field. To counteract this concern, the authors advise that apprentices ” be supervised by a series of mentors who possess varying degrees of mastery.” Additionally, they remind the reader that “no one knows everything” so it is ill-advised for an apprentice to be under the assumption their mentor is infallible in terms of their software development skills and expertise. By upholding this mindset, the apprentice may be able to recognize their mentor’s weaknesses without feeling like they have outgrown their mentor.

The authors also address the issues and concerns that coincide with reaching out to more experienced professionals within the software development field. They recognize that this task may seem extremely intimidating to most apprentices due to fears of rejection or being seen as “strange” by a potential mentor but they assure the reader that these risks are low when compared to the payoff of being mentored by someone who is much further down “the long road.” The authors also provide testimonial from a developer named Dave in which they illustrate these payoffs. Dave reminisces on the time he “uncharacteristically” approached a more experienced software developer named Wyatt at a conference and later went on to exchange emails with him asking to be mentored. Wyatt agreed to become Dave’s mentor and the two went on to meet periodically throughout a year. Dave describes his interactions with Wyatt as “pivotal in (his) progress” in becoming a skilled practitioner of agile development.

After reading this I plan on taking the authors’ advise by “lurking” on message boards and community web pages with the intention of finding potential mentors and valuable information regarding my particular field of study within computer science.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

I have to say I did not fully agree with this particular apprenticeship pattern. The authors reiterate their views from the other patters here by explaining that software apprentices should shy away from promotions that involve managing others rather than maintaining positions that heavily involve writing code. The specific context of the problem in this pattern is that you are being offered a promotion that will “pull you away from programming.” The promotion in question is one in which you may receive higher pay but will involve much less technical skills and require less programming.

I understand that the authors are trying to encourage readers to stick with programming in order to enhance their skills and write better code but I think that at some point in one’s career it is important to consider roles that involve management. Part of the reason I say this is because if good programmers never become managers than developers in the field will end up with lousy managers that aren’t understanding when it comes to handling difficulties a team of developers might face. Also, just because you take on a role that involves managing people doesn’t mean you’ll never write code again. For instance, many developers have side projects, such as open source projects, that are unrelated to their work which allows them to continue to hone their craft of software development.

I agree with the authors that developing software professionals should always continue to work on enhancing their skillset but I don’t agree on their anti-promotion/ anti-managerial outlook. Skilled developers occupying the role of manager may prove to be good mentors for those working under them. Furthermore, many projects can benefit from having someone with a strong background in programming making the important decisions. These decisions can range from architecting the project, choosing different tools and/or programming languages to use, and assessing whether applicants are a good fit for the team. If the only people managing teams of developers are those with little experience in programming then the teams could really suffer by not having the right personal with the right expertise and not having all the necessary tools/information they need to be successful.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.