Author Archives: Joe Barry

Sprint 3 Retrospective:

This sprint went particularly well. Cooperation between the team members improved, and the general effort and quality of the work effort exceeded my expectations.

With the rest of the team concentrating their efforts on the API and Backend projects, I spent most of my time writing and testing the remainder of the work in the Android testbed app.

This work involved finishing the coding and testing of the 8 main endpoints and adding code for the final endpoint, getRange.

The getRange method required addition of code to the NestTester, API, and Backend projects.

I also worked with the team on helping to get the backend to work for the getRange API call. We coordinated this with local unit testing from within the backend container using getRange.http calls, as well as remote integration testing from the Android Studio emulator.

This sprint included the time required for the 5 of us to prepare a video presentation. We are producing multiple mp4 files and will consolidate the individual pieces within the week.

Our usage of the GitLab Epics and Issues boards improved. This resulted in a better workflow, giving each team member a more balanced share of the task load.

Part of the sprint was used communicating with the IAM team to get a sense of the timeframe required to integrate security mechanism into our remote function calls. A plan is in the works for this integration to be implemented in next year’s Capstone.

I wrote about half of a document describing the steps that a future Android team can use to integrate my testbed infrastructure into the actual NEST app. I will finish this document in August when I have more time. I would have completed it this sprint, but the getRange development and testing was more complicated than we had thought, so had taken up more time.

Dr. Wurst had suggested that we can continue working on this project if we choose. Since this is an open-source project, anyone willing to contribute to it is welcome. I have time in August to continue working on this and will volunteer some time evaluating what needs to be done to migrate the testbed code to the proper locations in the “Live” NEST app, calling the mongodb backend from the proper places. I am not familiar with most of the NEST app code, so I would need to communicate with a contact from the team. Should I contact Dr. Burge from NCC for this?  This is all contingent on whether or not this is needed.

The capstone was a great experience for me. The 3 sprints showed how team members went from being apprehensive and overwhelmed by the process, to being excited and proud of their achievements. There are definitely “bumps and bruises” involved in this transition, but also a sense of pride in having succeeded. For our team, this seems like a journey showing them more about how the “real world” will work for them, compared with some of the more academic foundational classes they have taken.  

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

My First Programming Language (Blog 8)

In 1980, I attended a 3-month course at the Center for Computer Education in Lynnfield and was taught “Structured COBOL programming”. I then worked for the Commonwealth of Massachusetts Department of Welfare for 4 years, using COBOL as my first programming language. I had no real mentors here but did make a number of long-term friends. The lack of a mentor made it hard for me to progress as much as I did later in my career, where I had the advantage of working with some really smart people, so it is good that I learned to love computers early on at this job. I was pretty self-directed. Towards the end of my time at this job, I was able to work with some PL/I consultants who showed me what a “real” programming language was like. With this new knowledge, I was able to change jobs, and to double my salary first at MGH, and then at SEI corporation.

Around this time, I attended a course in PASCAL at UMASS Boston, and a PL/I course at Boston University. These jobs had people who were able to teach me some new tricks, but I also was able to return the favor to them. This lack of mentorship in my early years I look back on as a benefit. I was really “thrown into the deep end” in many places, which really helped me to keep learning as much as I could on my own. If I hadn’t continued to love computing, I would have certainly left my career in its early years.

I really didn’t get “Mentored” until I became a consultant, taught myself C and the Windows 3.1 SDK, and went to work at MIT. Through my consulting years, I worked at 10 to 15 companies, doing Windows UI development and SQL database work. These positions were both enterprise-level and desktop-level. There were about a half dozen people I considered mentors at these assignments, and I also sometimes acted in a mentor role to more junior employees.

I think it was fortunate that I was able to work at so many diverse organizations, because I became familiar with many new programming languages and software products, as well as obtaining a broad view of many diverse industries.

So, starting with COBOL, which I look back on and realize was a terrible language, I entered a journey which would continue to get more and more interesting as time went on. I have programmed in C, C++, C#.NET, PL/I, SQL, and a few others, but didn’t really feel I had found “The Language” for me until I started developing with Java which allowed me to convert to mobile Android development.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Blog Post #7 – Confront (and Expose) your Ignorance  

I am combining these two patterns because I think that one without the other will make for an improper balance of skills. This quote [1] by Carl Rogers in his book, on Becoming a Person [2] is very inspirational to me. I have made a career habit out of trying to be unique, self-directed, and perform self-directed learning.

I am also aware of the importance of being able to admit gaps in my knowledge to others. I will be the first to admit that I don’t understand something, or that someone else has a better idea than I do, especially when I think I can leverage this knowledge to improving my skills, and my personal development efforts.

Throughout my career, I have always had home-based software projects in play. The two most noticeable were Guitar Companion, (a Windows C++/MFC turned C#.NET utility program for guitarists which contained components for a notation editor, metronome, tuning fork, band manager, and video guitar lessons), and Guitar Chords, an Android app using MIDI, speech recognition, and swiping techniques to display an intuitive, pleasant looking, and efficient way to show and play any chord.

Although these efforts didn’t make huge sums of money, they did have the intended benefit of ramping up my skills in different areas, allowing me to learn from my home office, and then use this knowledge when needed at companies I worked for. The reverse effect also occurred. I was able to learn techniques at client sites, and then parlay this knowledge back to my personal efforts.

If I had not been willing to “expose my ignorance”, I would not have been able to learn many techniques from other developers. If I had been too focused on “confronting my ignorance”, I would not have done well at sharing back the knowledge I had attained on my own. This process was truly a win-win experience.

It is beneficial that as one grows in their career, they become progressively less concerned about others thinking they are not adequately qualified, because they have gained enough information to both learn and teach. This will lead to salary increases, better projects, better interviews, better companies, and ultimately to a happier career.

References:

1.“If we value independence, if we are disturbed by the growing conformity of knowledge, of values, of attitudes, which our present system induces, then we may wish to set up conditions of learning which make for uniqueness, for self-direction, and for self-initiated learning.”

2. Chicago. Rogers, Carl R. 1995. On Becoming a Person. 2nd ed. Boston, MA: Houghton Mifflin (Trade).

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective:

This sprint ran more smoothly than Sprint 1 did. As a result of having obtained a more detailed specification by coordinating with the goals laid out by Dr. Burge from Nassau Community College and having obtained a better understanding of the individual skill-sets of our team members, we were able to produce an OpenAPI specification that defined 8 of the 9 requested endpoint definitions. The yaml file containing these definitions was then used to write, build, and test these endpoints in our back-end container. These methods were then tested internally within the container by using the Visual Studio Code environment to launch HTTP requests from 2 files (guest.http and qs.http). “Swagger UI” was used as a VSCode extension to facilitate this process.

It was easier this sprint to distribute work among the team, because the Open-API spec was available shortly after the start of the sprint, enabling back-end code to be written and unit tested. As testing progressed, we would modify the spec as we made changes to the back-end code to fix bugs.

Although we did a better job at keeping the Git-lab Epics and Issues boards properly in place than in the prior sprint, this may have been the weakest area of our efforts. Our intention is to improve the ongoing modification of this Scrum material as we progress to sprint 3.

We improved our use and efficiency of GIT to Git-Lab coordination, were able to build semantic versioning, checked the structure of the Open-API definition with Swagger Preview, and started looking into using a secure key. This key will be coordinated as a priority in the sprint 3 effort through communication with the IAM team.

I was able to set up a fork of the NEST Android application with the intention of doing system testing of the REST API. By using Android Studio, my prior knowledge of Android development with Java, and the help of a guiding YouTube video, along with general help from stackoverflow.com community, I was able to write 6 classes in an isolated namespace to the project. This code uses an android library call Volley to facilitate REST API development. This code launches an activity from the main NEST activity which allows the user to make requests to the remote back-end MongoDB database, and returns responses, which are then displayed in a scroll-able text view component.

The layout used by this activity used a relatively new UI component called a Constraint Layout, which improves the efficiency and maintainability of its XML code with the support of a sophisticated design tool allowing “drag and drop” of components, allowing them to effectively present a user interface which will scale properly over the hundreds of different android devices, all with different screen resolutions, aspect ratios, and device sizes.

The system testing was burdened by the fact that calls from Android were producing a Timeout Error on every attempt. With the help of Dr. Wurst, I am in a better position to get these calls working by the first week of the upcoming sprint.

I was impressed with this sprint, because our team accomplished the 2 main goals of this classroom effort, the first being to improve the skill-set of the team members in a “real world” development effort, and secondly, to help with the general progress of the LibreFoodPantry work to produce a product to help those less fortunate than ourselves.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Accurate Self-Assessment: Be the worst – Blog # 6 

As a developer, I have always thought that “being a small fish in a big pond” rather than “a big fish in a small pond” was a great advantage for career advancement, both as a way to advance your knowledge, skills, salary, and position. I learned an incredible amount from other developers at EMC, Nuance, and Kodak, because these companies had teams where many of the engineers were brilliant and knowledgeable yet had no problem meeting with me to share information, and help with difficult design and debugging challenges. Although I usually obtained more from these teammates that I taught them, enough situations came up when I was helpful to them that they were happy to help me when I needed them.

I usually took the approach of only “bothering” them when I was really stuck on an issue. This had the benefit of making me fully understand the problem, and therefore taking less of their time. Before I would ask for a meeting on such an issue, I would take notes on what the problem was, and then write down a list of questions to ask. I found that some of the time, when I did this, I was able to get the answer on my own. Another interesting phenomenon would occur quite often. I would actually be able to come up with the answer to the problem on my own as I was going through the issue with them. I would then get a response like “See Joe, you already knew the answer. You just didn’t know you did”.

The whole concept of “sink or swim” is quite interesting. When working in a challenging environment, I was always more motivated to learn the skills necessary to produce solid code than when I was one of the more advanced team members. Since most of my career was as a consultant/contractor, sinking at a company was less problematic than when I was working as a corporate employee. The expectations of working as a consultant were usually higher. You were treated less as a team member by some also.

I found, though that I really liked both worlds. About a third of my career, I worked as an employee, and enjoyed the benefits of “being part of the team”, getting paid vacations, going to conferences for free, and the obvious sense of security. The other two thirds of my years in software either contracting as a 1099 or W2, or when I hung my own shield with my corporation “Twinstar Enterprises Inc”.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Use the Source: Blog # 5

This pattern explains the benefits of reading real world source code. If you are on an assignment and are asked to write a small component for the project, your most important task should be to read through the code-base and understand as much of the source code as possible, given the time constraints you are under. It is important for you to understand the intent of the application at a high level before studying the code, but then to immerse yourself in how the code works, how it is structured, what design patterns are used, how the class hierarchy work, and which developers were involved in the project. In most cases, it would be a mistake to try to learn all the project’s code, unless it were quite small. Consider understanding the code involved most closely to your intended assignment with the most priority. Most projects you will encounter are medium to large scale applications, and some would take you months to adequately understand.

Try meeting with the developer who wrote code most similar to what you are being assigned , and ask for tips and tricks on methods they used to build their pieces.

If you are asked to write, for example, an android activity that calls REST API’s, look for related YouTube videos, Google documentation, related code on GitLab or GitHub, textbooks, stackoverflow.com posts, and college library references, but most importantly, look directly at the code-base you are working with to find if similar code has been written which can be cloned, modified, and sometimes improved. I have worked on projects where the same basic code had been written more than once! Refactoring an application to remove repeated code, or to consolidated similar code is a huge time saver. There is nothing like management giving you a month to write something, and you come back in two days with it done. This is the type of “magic” you can accomplish if you are observant of the resources that already exist in your project, and the Open-Source world in general.

I also think it is important to read through code you have previously written. If you have resume entries stating you know a particular language or technology, a more than rudimentary understanding of it is really important for your next review or interview. As your career develops, the list of these items will increase, and some will become somewhat obsolete, so it is much more important to understand the most recent skills best. If you can’t recite a paragraph or two on any given entry, I would consider removing it from your resume.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Post # 4 – Construct your Curriculum – Make a reading list 

This pattern describes the benefits of maintaining a reading list of books on Computer Science. It suggests that you list of “Long Lived books” you have already read, as well as listing books you plan to read in the future. It reminds me of a number of books I have read that are essential reading for any developer. I have read “Code Complete”, “Writing Solid Code”, “The C Programming Language” by Kernigan and Richie, and a few others that are truly “Long Lived Books”. It is interesting that these books have stood the test of time in such a strong way, considering the accelerated progression of technologies. Most technical books and periodicals do not fall into this category. An example of this from my own experience is the plethora of books that appeared on the market when OLE, COM, and ATL became popular in the late 90’s. I bought at least 6 of these books, and they became obsolete rather quickly. As soon as a new release of these technologies occurred, a number of relatively poorly written books were pushed onto the market, having been written by authors who were more concerned with “time to market” than quality of information. Ultimately a “Best in Breed” book would appear, but this usually came out months after the release.

Your list should also contain books that you plan to read, sorted in order of importance to what you need to know currently, as well as those that you have discovered fit the category of long-lived books. Strongly favor the ones that have been recommended to you by mentors or peers but do your own research to find others. I have been helped over the years by periodicals. The better of them tended to have the better quality of writing at times of product release than most of the books being pushed at us. Some of my favorites are (were) MSDN Magazine, Microsoft Systems Journal, BYTE, Wired, PC magazine, and Computerworld. Keeping up with the mags was more helpful to my career than any of the books, with the exception of a dozen or so of them.

I kept a list of the books and magazines I had read I thought were important on my CV. This way, I was able to update my reading list whenever I was updating my resume. This kept the list fresh and up to date.

Now that we are exposed to audio books, blogs, podcasts, and YouTube videos, I tend to get most of my knowledge from them than from traditional books and periodicals, but the basic concepts of this pattern stand firm.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Post #3 for Apprenticeship Patterns: Rubbing Elbows 

Rubbing Elbows describes the benefits of developing relationships with other developers at your own level primarily. Working closely with others in a friendly, yet conscientious way is a skill set that is very important to develop. This includes working with peers and mentors, as well as those who are less qualified than you.

It is really important to have mentors. The book focuses on having one mentor, but I think there is room to have many. If you are lucky enough to end up in an environment where you are surrounded by many talented people, it is advantageous to you and to others, to gain information on subjects that will expand your career from anyone who is willing to help, even if it is just with a 5-minute conversation. Although you should learn from mentors, you can also be helpful to them in many ways. Letting them know you will follow up on minor problems they are encountering, or that you will do further research on what they are teaching you will help. Sending emails thanking them for their time, and briefly reiterating what they have taught, will let them know you are grateful, and serious about their advice. This will make them want to help you more in the future and will also make you appear to be a real team player.

The basic intent of the “Rubbing Elbows” pattern is to have you form relationships with fellow programmers at a similar peer level as yourself (Kindred Spirits). It describes the benefits (and difficulties) of working in “Pair Programming” situations, and will make your job more enjoyable and social, but it mostly will accelerate your professional development, as long as both developers are working to help one another. There are situations where you will be paired with someone who is just out to get themselves noticed, as well as those who are looking to take all the credit for shared work, so be careful who you decide to focus a lot of energy on.  

To expand on the pattern, I would also add that I think it is equally important to help those of your peer group who may be struggling on a given issue you know more about, and to help those who are less experienced as you. These people will be grateful to you for your assistance and may end up helping you over the months and years ahead far more than you would think.

This pattern is also applicable to those you meet outside of your job. Those you meet at conferences, training courses, and Computer Science related clubs, as well as those you “meet” online in forums like stackoverflow.com can be very helpful to your goals and could actually become long-term friends.

The bottom line is that you can learn from anyone, and you can teach anyone, as long as all parties are on-board with being respectful to each other as individuals.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective:

Our team is in the process of developing an OpenAPI specification to connect the NEST android application to a remote MongoDB database. It currently uses a local SQLite database to store its Guest Information System data. There are 5 developers in our scrum team. Our sprints are 3 weeks long, with each developer being allotted 6 hours’ worth of work in a week, over and about the 3 hours per week we are using for class time and scrum meetings.

The project started out with 4 Epics, which we broke up into 18 issues initially. The 2 primary epics were API and Backend. Given that the backend work couldn’t be specified until the API was defined, we had to be creative in how we distributed the work. Since the team members were not that familiar with the specific skillsets of the other members, it was difficult at times to determine who would be assigned to which tasks.

I acted as the scrum master for this sprint, which was surprisingly difficult to manage. The majority of my time was spent trying to figure out the API and adding a basic framework to our docker API project. Other members of the team developed container shells for the API and Backend, as well as adding documentation to our general and documentation repositories.

We ran into issues where issues were designed too vaguely, resulting in some tasks being defined twice. The team did a good job of giving weights to tasks, but we could use more effort in knowing the status of each individual.

This may have been an error on my part, but the scrum meeting task of each developer telling (1) what they have done, (2) what they now will do, and (3) if they had any questions turned into longer discussions, therefore not giving enough time to other team members to communicate enough.

I communicated with Professor Budge from Nassau Community College, who teaches an Android class at that school, and is a key contributor to the LibreFoodPantry product. Since our correspondence took 10 days to solidify a general design, I had jumped the gun on the task of developing the OpenAPI by assuming the full contents of the SQLite database were to be stored in our database, as a result, I developed a plantuml design for 8 tables that were not ours!! https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/tree/main/bundles

I also produced a yaml bundle of the Product table. We decided during sprint 1 review that this work should be offered to the FoodKeeper team, another subgroup of our Capstone class.

During the last week, Dr. Budge, after a series of emails, led me down the right path for what we will need to do over the next 2 springs. We are responsible for the data in 2 tables (collections on MongoDB), QuestionnaireSubmission, and GuestRepositoryEntry.

Our sprint’s work should probably have been more focused on design than it was. With people new to Agile/Scrum and some of the underlying technologies we are using, in retrospect, it is clear there were mistakes in our process we will learn from. I think the main message is that until a design is cast in stone, then any technical efforts afforded to the project before the design is solidified should be considered as disposable.  

As a team, we spent a lot of time considering our methods for testing what will be written. At first, it seemed that best approach was to use swagger preview to test the API, given that the backend wouldn’t be in place yet to test with actual “curl HTTP … “calls.

It has now become clear that we really need a new Epic to fully system test the project. W\Three members of the group have built Android Studio and/or Visual Studio Code version of the NEST application itself. The new Epic could outline the work necessary to make a test version of the NEST app to do the actual calls. This will dramatically help the team that will be working on the NEST app next fall.

I have decided that I will relinquish my role as scrum master for sprint 2, which will give another team member a chance to gain experience with this job.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Post #2 for Apprenticeship Patterns: Perpetual Learning: Breaking Toys

The Breakable Toys describes how to set up a situation where you can continue to learn and make progress with your career without unduly affecting your performance as a developer on your “day job”. The idea is to create a home-based work environment where you can develop product to enhance your skill set by making small products on your own. If these fail, or turn out to be flawed in some way, there is no downside, because you are expected to have learned lessons on your own. Although most work-paces are reasonable when your coding doesn’t come out perfect the first time, it certainly is much better for your career if you develop working, useful, optimal code in a reasonable time frame.

Many developers don’t have the time or inclination to do this, and turn out to be productive employees, but those who guide their own career by making their own products on the side are much more likely to succeed both intellectually and financially.

Throughout my career, I have always been motivated to keep up with the current journals, attend classes and conferences, and to always have a product I was developing on my own. In the 1990’s I developed a music-based utility program for guitarists called “Guitar Companion”. It’s most impressive component was a notation editor, but it also had a metronome, tuning fork, band manager component, and 3 CD’s with Video Guitar Lessons. I wrote it in Visual C++. But over the years, converted it to new technologies, and sold it through a website I had constructed fo4r this purpose.

From 2010 to 2015, I developed a number of Android applications for musicians. The one that turned out the best I sold on Google Play and had over 20,000 downloads.

This was all great for my career growth, but I would have never done this if I were not passionate enough to put in the time and effort. I highly recommend this approach to anyone who really loves to code. You are your own CEO. You call all the shots. You become sought after by companies, because you have developed depth in your code base that few can attain working under the strict protocol of working for someone else.

It also works in reverse. I would incorporate functionality into my “Toy” products that I learned at job-sites, as well as using things I wrote at home into my work products. It is pretty great when a boss asks during a scrum “who knows how to do X”, and you raise your hand. “ I do”.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.