Author Archives: Julion DeVincentis

Sprint #1 Retrospective

At the beginning of the sprint a general overview was collectively made by the group and some confusion over the scope of work completed so far occurred. We were expecting a majority of our work to be code refactoring but at the time it was noticed that there was no actual operating code to refactor really, and our collective effort was directed at simpler cleanup tasks.

During the first sprint I assigned myself to two tasks created by Sebastian:

1st https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/61

2nd https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/2

The first task was creating landing pages for to later connect to the second task which was assigning href links to those landing pages.

I specifically chose these as I have never worked with html except for one occasion earlier in my youth during high school. I felt like this was a good opportunity for learning html and getting familiar with it as it is something I should know how to work with on at least a basic level. The majority of my time was spent on learning how to code in html and dealing with what I considered to be how weird it handles spacing and formatting.

My general experience with learning html did not go as well as I hoped. As with learning anything new the tricks of the trade generally do not surface early on and instead are buried deeper in more specific tutorials.

I generally struggled with spacing and formatting and in specific aligning a couple text boxes until my fellow team member Kurt off the top of his head mentioned that you could add spacing and tabs with specific code that made the pages look slightly more organized. He also told me about CSS and I spent some time learning about that and bootstrapping to find an easier way to automate the formatting of the landing pages.

Now I could have originally finished the landing pages and connecting them to the main landing page, but I had decided that without a more complete formatting style and still uncertain as to the future of those landing pages (the way the users will be directed to these pages depends on the Keycloak and Kubernetes systems being developed by the other teams and might require a complete design change to those landing pages), I chose not to finish the landing pages during the first sprint.

The second issue relates to a far simpler task that seemed a bit more difficult at the time but as I discovered it was far simpler. At the start it seemed like I might have to create other structures in the other front ends for linking together all the landing pages. Luckily after looking over the code it seemed to me that all I would need to do to link the landing pages together would be through the one hub located in the header.vue in the addinventory front end. It is the one point that has the href linking to the other front ends and I’ll be likely directing the landing pages from this point. Ultimately again it wasn’t implemented as the formatting was not completed for the landing pages. Overall I spent far too much time kind of randomly learning html and felt like I needed to find a more organized path to learning html. I also am expecting during the next sprint to have a far more coherent style and to format it based on Worcester States’s general website formatting and color scheme, as well as actually creating the pages and linking them together to finish these two issues

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 1 and Introductions from Chapter 2-6

Generally, I haven’t learned much more than I already know from the first chapter and the introductions from the next five. Not to say that I didn’t learn from them but rather the concepts they covered kind of seem like common sense in terms of how to approach learning and getting better at your trade.

I did enjoy the parable about the master and the apprentice in chapter two, although the ending I found a bit lacking. While yes, the point stands around learning to keep your mind open and not let your previous experiences hinder your learning, I find that the foundation of what I have learned is what I use to stand on in order to walk into a new subject. The focus of the parable being that at every introduction to a new line of thinking from the master, the philosopher projects what he knows rather than waiting to see if there is something more to gain, thus his cup being already full. While I get the meaning of the story, I feel like it’s ignoring the side of the philosopher even though he is at all turns preventing himself from learning more.

I did enjoy a quote from George Leonard in the introduction to The Long Road. It does make quite a bit of sense that regardless of mastering something there is always more to learn, and that your journey is never over.

Chapter six did in a sense reaffirm the need to create my own pathway to learn. I’ve tried before hoping that I can kind of just find my way around the internet to learn programming and developing software, but I always meander about and never really develop anything really concrete. Unlinked lessons that show you how to begin rather than how to fulfill that journey are abundant online and most times are the first results of any search. Some reading material I have enjoyed, but most books seem incapable of passing on actual experience from the concepts they describe. Kind of like learning algebra in school only to ask yourself at the end of the day what can I even use this for and not being able to come up with an answer.

I think this book focuses on an essential process of really learning anything. To approach each subject with a clear mind and not boxing it into the same category as “something you already know”. To remember that there is always more to learn even if you end of being the “big fish in the pond”. That just learning alone isn’t enough, sharing and learning from others is paramount and the idea behind the concept of being an apprentice. I kind of feel like this book shouldn’t even mention the idea of becoming a master when it focuses so much on continuously learning. I’ll probably get a clearer picture on the intended lessons to learn when I read more from the book.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Thea’s Pantry

After looking over the gitlab page about Thea’s Pantry, I was intrigued as I never have gone to a food pantry before and had wondered how this software was going work with a repository of food. The User Stories page described clearly how a guest interacts with the software and how it has a place in gathering the information necessary and recording what is taken from it. It also listed categories about specific donations as well as which values can be chosen for how the items were donated. I honestly didn’t quite know what to expect but this listing made it clear to me how the software was going to be used. I at first thought it was going to be more centralized around inventory management but it’s a bit clearer to me that it also records who used and donated to the service.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

LibreFoodPantry

After reviewing and reading over the LibreFoodPantry’s main page I found a specific topic that settled a concern that I had about working on an open source project like this. In it’s values page it presents a list of ideals titled FOSSisms, where I found a particular one that I wasn’t expecting. This FOSSism covers how a student like I should handle working on the project and worrying about making mistakes or asking permission to try working with anything. I know that this semester I’ll have tasks already set aside that I need to work on but actually doing it and making a mistake that could break a part of the software itself was overly present on my mind. This FOSSism reassured me that I shouldn’t be too concerned about making that mistake and rather to ask for forgiveness instead of first asking for permission.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

JS Error Handling

In this week’s blogpost, after seeing a piece of code in a previous assignment I wanted to learn a little bit more about what it actually was. The piece of code in JavaScript used async and await, and me being a novice in JavaScript didn’t exactly know what it was, but did a little bit contextually. At first glance they seem like timed functions to synchronize something. In exploring what these were I came across this article on error handling in JavaScript.

https://www.valentinog.com/blog/error/

This blog goes into great detail over error handling in JavaScript, and I’ve learned quite a bit more as well as answering the async and await question.

First off, I did not know that JavaScript was single threaded, meaning that it doesn’t utilize multi-threaded processes to handle certain bits of logic simultaneously. The article gives a good example with a timed error throw with an error catcher to demonstrate how the try/catch will already execute before the error would ever be called.

I was also introduced to some new interesting features of JavaScript like Promise. Promise is indicative of it’s name and is basically like a promise of the code to catch up with each other later. Promise uses “.then”, “.catch” and “.finally” where the only real difference is in name for “.then” as it’s the counterpart to “try”. It also has some more singular uses like “.all”, “.any” and “.race”. These are just different methods for finding an error. All will take an array of “promises” and find any of the errors from the promises and return the promises that resolved. Any will give you the first of the “promises” that resolved. Race is basically just a race to see who completes first regardless of error or not.

Asny and Await are two functions that you generally prefix to another function. Async forces the function to return a promise which allows us to use the Promise “.then”, “.catch” and “.finally” to resolve outside the function. But it doesn’t also mean that we can’t use try and catch as with “await” it allows us to literally wait for a function to resolve and with try and catch we can handle the errors inside of the current function.

Overall this article was very helpful. My intention was to just find an explanation as to what async and await meant, but I ended up with a little crash course on interesting ways of handling errors in JavaScript, as well as clear meanings behind each one.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

JavaScript Best Practices

As a trend from the previous posts, I am still working with JavaScript, and I am still learning more and more about it. In this article I learn some best practices around JavaScript itself. Some new things and some things common for any programming language.

https://www.w3.org/wiki/JavaScript_best_practices

There is not much to summarize for this article as it is simply some best practiced coding techniques for proper JavaScript coding. Like mentioned earlier it does include some things that by now I should already know and practice. As in comments should be as needed but not in excess, naming conventions should be simple and understandable, Big O notation matters and to optimize your loops and avoid nesting them and keeping to clean code style of one function one purpose instead of excess purposes inside a function that might be iterated out later or nonsensical to someone code reviewing. But there were some more JavaScript specific practices that were more related to web development.

                Progressive Enhancement is a concept that I get on a basic level just thinking in terms of providing a service to someone means going through the barriers of your platform to make sure they have access to it, like Microsoft office products working on mac. In this article it mentions the idea that when scripting or perhaps even JavaScript itself is not available to a platform that you need to manage the code in a style that will work with any platform. To me that seems easier said than done but it does make sense that if the interface to the user can be managed by something else before scripting is done then you achieve your goal of progressing your user base and opening your code up.

                Another practice I learned was regarding data security. That at any time any data being passed through my code should be checked first. I have heard examples of specific businesses being hacked due to a very specific fault in the design itself that left open vulnerabilities which lead to personal information being stolen. Most cases I have heard is simply the human aspect in security vulnerability where a hacker just calls to get access to a password for an account that can then access that data. But in the examples given in the article it is specific to making sure that the data passed to you does not fault in error and that there is some methods that allow you to discern data types from another to avoid further conflicts or generally avoid validation on the users end to prevent them messing with your own websites code.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

JavaScript and Classes

In my previous post I linked an article I read about some basic things that I should know about JavaScript in my attempt to get more familiar with the programming language for my computer science course this semester. This post is a continuation of the last and necessary to getting me up to speed with JavaScript and how my course is using it. So far I have only programmed in languages like C, C++, Java and not a typescript based language. The languages I used were more object oriented and I came across this article below that caught my attention. That you shouldn’t use classes in JavaScript.

https://javascript.plainenglish.io/why-you-should-not-use-classes-in-javascript-ca960d13c625

Funnily enough the article starts off with a mention to Scheme, the first programming language I learned in a college education setting and a language I never touched again after that semester. It turns out according to the article that JavaScript itself was supposed to be based on Scheme. So, here’s hoping some of what I learned from Scheme will be beneficial down the line when I learn more about JavaScript.

One of the main issues described in the article relate to binding. That with JavaScript even referring to an object that was class defined requires the exact context in relation to it’s call. In his example it shows ‘this’ being used three times just inside the constructor method for creating the function. I haven’t really ever seen a class defined yet in JavaScript so all the humorous jokes about the language I have seen so far are starting to make a bit more sense (like an endless chain of this.myfunction.this.myclass etc etc).

Another Issue raised in the article is the fact that you apparently cannot create private variables in JavaScript. In the example shown it makes it pretty clear. I was honestly kind of shocked considering it is such a common thing used in every other language I have learned. This is definitely something I need to remember about JavaScript to avoid future errors if I ever have to create a class and intend to use encapsulation.

This article ends on the note that the author has a preference for factory functions, a topic I had only heard of and learned during this semester. While the list of reasons to not use a class are I feel minimally an issue it does help me understand that JavaScript is generally less focused on class based structures and more focused on just using objects to avoid some issues from JavaScript and issues from OOP in general.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Javascript

On this post I decided I need to catch up on learning javascript for my homework assignments, having no real prior experience I needed more than just the simple basics but rather things I must know to succeed and not be confused. Which lead me to this article below.

https://dev.to/deen_john/resources-to-master-javascript-3d0p

I have honestly not done any web development aside from a brief exposure to html in high school, and while I did get some experience with javascript I didn’t experience enough to retain any memory of it. So this article above has not only the fundamentals in forms of multiple links and tutorials, it also contains a plethora of actual content in the article on each subject that is brought up. Often searching for articles on javascript it would be just a repository of links, but this is structured with other links prior to an example given as well as an explanation.

Right off the bat the type system was interesting to learn about, considering that the types are not actually different but the syntax is quite different as well as coercion being even a thing is interesting. That you could multiply a string and a number and get a number due to implicit conversion.

Another interesting thing I learned is that every value that isn’t a primitive value is an object. So variable1 = 500; is a primitive value so it’s simply just a number value. If it doesn’t contain a primitive value of any kind it will need to be defined as an empty object with {} after the name declaration. There is no item declaration type like int or short or double. There is just var name = (primitive value) or {empty object}.

There was also another interesting thing that I didn’t expect was that null is used as an object and that undefined is generally there to show that a value has been declared and not assigned a value.

I also learned about truthy and falsy, and in specific I was surprised to learn that the Or operator didn’t quite work like I expected. Generally, when using Or there are three conditions I would expect and one I wouldn’t worry about. The first operand is true, the second operand is true, neither operands are true and lastly both operands are true. With the first, second and fourth resulting in a TRUE, I was surprised to learn that javascript only cares if the first operands is “truthy” otherwise it returns the second.

This article helped me a lot and will at least give me a head start and not be confused when I try using Or and expecting a positive result and not just the second operand. It seems unintuitive in some regards but it may just seem that way due to me being so used to the other operators for such a long time.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

NoSQL

During this semester we have started to use MongoDB. While I did get some general explanations of MongoDB in class, I felt like I needed to get a better grasping of how MongoDB works as a database and how I can better use it. Since MongoDB is a NoSQL styled database and my general understanding of databases comes only from using relational databases, I felt like an article helping to summarize and clarify NoSQL would be advantageous.

https://dev.to/lmolivera/everything-you-need-to-know-about-nosql-databases-3o3h

This article goes into great detail not only the advantages or features of NoSQL but the terminology used alongside with it. It has descriptions of multiple types, how they differ and what they are used for and including some helpful guides around designing these different types of databases.

More specifically my focus is on the type of NoSQL database that MongoDB is which is a document based database.

As the article describes, a document type database stores it’s data inside of a “document” that could contain varied types of data. Even to the point of storing documents nested inside of other documents. Which highlights the advantage of this type of database which is scalability. Being able to store nearly anything inside the database and not needing to force it’s formatting is a great feature. I’m trying to think of a scenario needed for nesting your entire database inside as an object containing your entire database. I don’t seem to be able to think of one in specific, but the concept is interesting to me and maybe it’ll be useful later.

This article also briefly goes into describing how JSON formatted NoSQL databases are structured. This was good to see as this is exactly what I have been using in class as well as in the most recent homework assignment.

It also gave a link to a list of databases who have used Document based NoSQL databases and was interested to see eBay listed their and specifically using the same database MongoDB as we are using in class.

https://www.edureka.co/blog/real-world-use-cases-of-mongodb/

Near the end of the article it begins to describe the CAP Theorem. The theorem as I learned from this article to be a general issue around picking which attribute we focus on for the service. Is it frequently consistent with reads/writes? Does every request have the most recent changes? Does it still perform it’s functions when some of the machines are currently not connected? This concept details that you must pick only two and generally partition tolerance is chosen first as one of the two. The reasoning being that as a service being able to provide it regardless of a particular aspect of the database going down you still want to be able to provide a service.

Overall this article gave me some good general insight on what a NoSQL database specifically is and how it is generally used and will help me in class when referring to the database we have been using MongoDB.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Technical Debt/Cruft

Hello everyone,

https://dev.to/6figuredev/episode-207-tech-debt-vs-cruft

This podcast in particular talks about technical debt in detail, as well as how to handle it. It introduced me to a term I had never head before called Cruft. Cruft being not traditional technical debt but specifically a type of debt where the developer who wrote the code did not make the effort to make the code clean and or work well. I never made the distinction in my own mind as to consider the possibility that the lack of best practices or simply writing the code wrong could be considered as that type of technical debt.

Now I don’t mean the developer was malicious or perhaps lazy, while it could be considered a possibility it seems to be not a scenario that happens enough to be something that requires a term like that. I also like having that extra terminology as technical debt as a definition can be left to an intentional design choice that leads to the creation of technical debt that most times are made in consensus rather than specifically one user not knowing how to code it or that user writing poorly designed code.

Cruft also gives a more specific term for a business to focus more on as it has the greater debt value for the company when needing to rework your product. If the code is rushed and written poorly, when errors arise the pressure is greater on the development team and will lead to failure or delays.

With Cruft as the core of that perspective on technical debt, regular technical debt can be just the debt that was planned and agreed upon allowing you to release and work on it later.

This podcast also introduced me to another great term that is separate to legacy code. With legacy code it’s old enough that it doesn’t meet the definition of Code Rot. Code Rot isn’t keeping up with older code so old as to be legacy code, but code that hasn’t been touched in a while and isn’t kept up to date with the newer builds and similar code design.

From this podcast it gave me an interesting mindset when thinking about a production cycle and acknowledging technical debt as kind of being inevitable and something to try to plan before sprints as apart of the team and being prepared for it. Cruft is really what I thought technical debt to actually be, because I was only really reflecting on code being written by one person. I for some reason ignored the aspect of working on the development team and it has changed my idea of development. Cruft really is just a more personal or workspace issue. One being fighting against the urge to take the easy way out and the other being a pressure outside what I as a developer couldn’t control but rather a business forcing the cruft to occur by forcing shortened deadlines.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.