Author Archives: aadelinia1

Sprint Retrospective 6

What seemed like a doomed end for us, eventually our team got great results in the end, even though we started out very rough. In the first few sprints we definitely bit off a lot more than we could chew and almost put the component in jeopardy because of this. But through our team’s efficient refocusing and discussion we had a component that worked. During our final sprint we spent most of the time trying to figure out a lot of the CSS work. One issue that we also ran into was that we had a lot of issue when we were trying to merge our component with others. Eventually we found out that this is mainly due to our node versions being different and our use of Ignite UI imports that were absent in other team’s components. The reason these were absent in other team’s components was because the base angular material design api already included certain components that the other groups needed, whereas our component needed this other library. We ran through the other merge conflicts on git hub and managed to resolve them all with relative ease.

With the various obstacles we overcame, and the points at which it seemed all hope was loss, these sprint taught me a lot. This whole project taught me a lot about team building and resource management. This class gave great insight to our team building skills and how satisfying it was to overcome obstacles as a team. Through collaboration with other teams it was great to finally get past a certain roadblock or figure out that one syntax error that you got stuck on. It was a fun experience working with classmates that I never had worked with before because we all now have a greater sense of what team building is all about. These sprints were a great way for me to really understand what it takes to work together to find a solution, or even by yourself to figure out how to incorporate findings into the team. Although we had a challenging start, we made it to the end. And although not everything is as complete as we would like it to be, it still a great accomplishment.

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

Sprint Retrospective 5

From the last sprint, our team was entering this new sprint with a lot of questions as to whether or not we could complete the server. After a lot of team discussion as to what we think is best, we ultimately decided to drop the server (for now) and start working on an actual component. We were all really frustrated that we had come to that standstill with this server and it seemed as though no light would come of day. But with the internal discussion we had and rethinking processes, we decided that it would be best to just start for production on the bottom navigation bar component. To start, we talked to other teams as they were essentially done with creating an intractable framework for their components. After talking with them for a bit, we understood that a lot of the work was actually already handled by the angular material design. A lot of the components that were needed were built into the API and could easily be implemented…except for ours. Figures right? However, it wasn’t all doom and gloom. When scouring through the angular material design api, we saw components for forms, side navigation bars, tabs, and much more. However, what we didn’t see any documentation for was for a bottom navigation bar. A static module that was always overlayed on top of almost every other component and was responsible for switching to different pages or fields when needed. Fortunately for us, we found was was called “Ignute UI”. This was a lifesaver and a time saver. Like the base angular material, it had all the other components such as forms, tabs, etc. But it also included the bottom navigation bar and much, much more!

Our team was relieved and immediately started implementation of this within the component. The API was very clear and had java-doc like documentation with greatly explained what was included in each package and component. This was exactly what we were looking for. We finally got the navigation bar implemented and working successfully! This was a great step ahead and major improvement after the essential devastation that was our last few sprints. Our team came together and persevered to find something that worked, and this Ignite UI could potentially be even more useful than the base material design to consider using in the future. But for now our focus was to test this component and start to match the CSS as it looks on the Zeppelin layout.  It’s feels great to finally be able to move past a barrier that we have been stuck at for so long now and to finally see something that we can actually interact with. A component that we had initially thought to do but put it to the side. It seemed like we had to restart several times but finally we have something that we can show and something that can finally start being merge with other groups in hopes to create one large working component to finally interact and share data through.

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

Sprint Retrospective 4

Throughout this sprint we attempted to get some services successfully mocked and hopefully start the integration process within components. One big issue we ran into was that our team was very confused as to how to continue from the point we were at. It seemed that a lot of the services that we traced just led to more mundane methods that did not really help us at all with any information that we needed for anyone’s components. Some of the patient profile services has some type of data to return. But what we found was that a lot of the services were making calls to URL’s that we had no clue as to where they led. We are pretty much stuck at a wall here. The way that we initially understand was not really completely thought out when it came to execution. Our main issue is that we understand that we need to mock only the important services that other team’s components require, populate them with data, and make it able to ping back to those components. However we are unclear of what to do from here. As I previously stated, it seems that the architecture of the ampath services were far larger and a lot more cryptic than we initially thought. Even though we have hit a big wall, our team is always trying to push through and are really trying to understand every aspect of what makes this issue an issue so that we can hopefully work past it.

Right now, our focus is to reconsider if this was the best choice for us. We have been actively consulting with other teams and Professor Wurst to try and come up with an efficient solution as to not create any unnecessary overhead. Admittedly, it seems as though we bit off way more than we can chew in this instance. What I believe our next plan of action will be is to actually development one of the components so that we can actually have something tangible to work with first, that way we can see if we can recoup for our loss on time of the server by mocking for components that will be directly relevant to us. We plan to work on the bottom navigation bar and sort of leave this roadblock where it is so we can still be efficient with our team. One of the things about coming to a road block like this is that it teaches us that sometimes not fully understanding things could actually be more of an issue than we thought. And this is not to say that we haven’t learned anything from this experience, because we have, rather it’s more of an eye opener to maybe scout out the road ahead a little bit better. But again, we are still going to actively try to work on this but for now we are putting it on the back burner until we can get something figured out so that in the future we can hopefully start compiling other components.

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

Sweep The Floor

Whenever you are new to a team, it an be very nerve racking because you do not want to mess up a single thing. This mindset is perfectly normal and makes sense.  This pattern discusses newcomers into a project and what to do in this environment. For starters, it’s always important to make good relationships with your team. The situation is that you are a new apprentice on project and the team is unsure of you. You want to find ways to contribute to the teams work but you can’t overdue it. This pattern explains that y ou should volunteer yourself for simple but necessary tasks. There are always going to be certain tasks that your team will need to get done one way or another, and even though they are simple tasks, they can often enable for the future success of whatever project you are working on. When taking these tasks, you should still pump out a high quality job. Showing that you can perform even basic tasks at a very high standard of quality shows your team that you care about what you are doing even if it is just small tasks. Sometimes these tasks can be just as vitally important as other tasks. Some examples of these tasks are maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, or even setting up the project wiki. However, it can be tough to do if you spent a lot of time and money on computer science education. The reality of it is that when you get into the workplace, our education is worth a lot less. When you join a computer team, getting hired is different from joining a team. Your firsts takes should be made to send a message. However, there could be some potential downfalls to this pattern. It could keep you permanently doing these mundane tasks for the team and never giving yourself a chance to expand to bigger and better things yourself. But if you do the tasks that sometimes your team may not want to do, it could give you a sort of priority on what you can do next for the team and open new opportunities for your team to see how worthy you are.

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

Sprint Retrospective 3

This sprint we ultimately ended up with choosing to work on the server. This server would be responsible for handling data transfers between all of the components of the groups. Our group had an internal vote between working on the server and working on the bottom navigation component, we all agreed to work on the server as we wanted to challenge ourselves and learn something that we have not done before. Learning something new seemed to be in the interest of all of us, and especially myself. Whether or not we can do this or not will be interesting because no matter what I feel as though we can learn something as a team.

When dealing with a servers it is very important to understand how services work. A server provides services to one or more clients and a server is the computer. These services are what makes these servers available on the network. In order to understand how these services work, our grouped delved further into this topic. We searched through ampath and found the folders that contained these services. These are the services that we will need to recreate in order to make the other components work. The catch was that we only needed to find the correct ones for each team’s respective component. We came across what is called “nock” to help us with mocking components. Instead of pulling data from servers, instead we need to pull data from a predefined list of attributes somewhere in the code. This is precisely what nock is designed to do. It overrides node’s http.request function to use modules directly.

Now that we have established what we are going to be using to mock these requests, our task was to now pinpoint these services. We started a backlog of services that we needed and plan to consult with other groups to see what type of form data is needed so that we can find the respective services. We have been communicating using slack, not only with our group, but with other groups to see where their progress is. We also created designated channels for discussion about pinpointing these services that we need to mock the requests. So far, nothing has really started for us as a sort of production, however in the coming sprints we want to start really engaging more with other groups and want to start designing the basic frameworks. This server seems like a big deal, and if pulled off correctly will be great. Trying to build and design something that is brand new to you is very intimidating and possibly time consuming, which is also part of the reason why we are trying to educate the other groups to have them help us find what specific services they need to we can work along side them to have a smoother transition when it comes to mocking the data. Hopefully we will be able to start gathering the resources and information we need by working with these other groups to secure these services and hopefully correctly map their locations.

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

Practice, Practice, Practice.

We all want to get better at something but we often don’t really know what to do to get better. Sometimes, we can find ourselves repeating the same mundane tasks in hopes that something will just magically change or snap and we will be better at whatever it is we are doing. However, this couldn’t be further from the truth. When trying to get better at programming, you often have to practice things that you are not comfortable with. That’s just how learning works. In order to learn something new or get better at something that you need to improve on, you need to step out of your comfort zone in an environment that you feel safe doing so. Although practice may not make perfect, it does make permanent. Even if you are trying something new and you don’t quite get it right away, all that practice beforehand and grinding will not be of waste. You will just be reinforcing your skills, enhancing you previous knowledge. This pattern is great because it tells you to just keep working at whatever task you want to get better at. It also points out that just because you are repeating the same thing, that doesn’t mean you are not getting better at it. Choosing the right thing to practice every day is just as much as a skill as repeating something a lot. They are both important in that you are learning and reinforcing at the same time. Some of the books that the article pointed out that are good ways to ensure you have interesting exercises are Programming Pearls, More Programming Pearls, and Etudes for Programmers. The authors of these books understand that getting fundamentals deeply ingrained does not stop being useful. Practicing anything, as long as you understand what you need to do, you will always get better at something. That is just how practice works. Even if you think you are not getting better, you are still simply reinforcing already known ideas. This pattern is a great example that you can still try something without the fear of failing, because you just get better at it regardless of the outcome.

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

Breakable Toys

As much as we want to obtain success, there is always something that leads us through that road. This pattern of “Breakable Toys” explains how there will be a point in our careers where failure is not an option. But this contradicts something that we have been taught our whole life. That failure is one of the best ways to learn. If you are conservative with everything you do and never step out of your comfort zone to try something new, then how will one succeed? An example from the pattern is that sometimes people already expect you to know everything about the issue. This can be common in certain jobs as well. One tool that this pattern suggests is to create your own wiki. This is a great tool for an apprentice because you can record what you learn. If you maintain this wiki, you can teach yourself about a ton of different topics. But the most important thing about this strategy is that you have better knowledge retention. By creating a wiki you are essentially creating your own personal archive of information and learning. Sometimes when you create things, it’s better to create toys that suite your needs. Sometimes these toys can just be rehashes of your version of some sort of industry tool that you can mess around with and learn from. This pattern is all about creating something you yourself can learn from. Building something that you can build upon in the future and continue to learn and implement. It’s about stepping beyond your boundaries and completing full software projects on your own. You should use a lot of your previous knowledge and skills to enhance them. Over time you can add a lot of features and even expand your wiki. I like this pattern because it is something that will grow with you and level you up. So there is no need to fear of expanding upon your own tools. With these resources, you should be able to act without the fear of failure in your workplace. This is preparing you for using the the tools in your job that you won’t mess up because you will have trained yourself to do so.

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

Craft over Art

This method talks about how indulging in your own artistic nature isn’t always the best option even if you think the product would turn out better if you did it this way. If you are being paid to build something that will solve a problem, this method of Craft over Art explains you need to really consider the situation at hand. In this method, the situation that is discussed is that you believe that you are able to do something outstanding and fantastic that will impress your colleagues. In this situation, you are building something for a user. You shouldn’t be indulging in artistic expression. A lot of the times when we are handed with a task, we can sometimes think about the most outstanding ways to do something, rather than just to get the task done. This can go two ways. Doing something outstanding for a task can be great and have it’s benefits, but what will it cost the effectiveness of it? On the other hand, we can do the task at hand and that will be that. We won’t be able to put any personal expression in it, but is that a bad thing? Of course it isn’t a bad thing. This method seems to be very similar to function over form.

It is a matter of situational awareness. This is something I really enjoyed from this article. Make more straightforward choices and do not try to “sugar coat” solutions. As soon as you start making unfavorable trade offs in certain scenarios, the outcome will not always be as you like. in other words if you want a straightforward answer, you should provide a straight forward solution. Even though this isn’t always the case, I learned that you should always try your best to just try and perform the basic tasks first without adding anything extra or unique. Quality takes time, but having the correct operations in a product is what can make all the difference.

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

Sprint Retrospective 2

For sprint two our group was in waiting state. We didn’t quite have any tasks to work on at the moment and we were conflicted on where to focus our future workloads. We know we want to work on the server but also are coming up with a backup plan in case that does not work out. Our group worked  a lot towards researching certain aspects about how servers work and talked about what incorporation we might need from other groups.

During our research, we found two tools that we plan to use for testing. These tools are useful in that Karma is more of a simple junit tester while protractor is end to end testing. As we continue to research more tools, we also want to familiarize ourselves more with the angular material. Angular is more familiar to us which is why it would be  a good idea to work on the bottom navigation bar, however some of us enjoy a nice challenge too, which is why we would want to work on the server.

Hopefully by our next sprint we should have more solid understanding of what we want to do. We are most likely going to be working on the server but no one in our group has worked on one before.

 

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

Confront Your Ignorance

This method talks about how there are tools that we need to master but we may not always understand how to master them. A lot of the times we try to be a master of all, when in reality that doesn’t necessarily work all of the time. What I mean by this is that when we are faced with  a task, sometimes we think we understand each little aspect of the specifications. However, upon actually tackling that task, we aren’t really sure where to go. Like one of my previous entries on “Exposing Your Ignorance”, confronting your ignorance really focuses on selecting on skill, tool, or technique and really honing in to fill gaps in your knowledge about it. One of the points in this method that really caught my attention was it’s mention of humble, ignorant, and dependent team building. If you are working with a team of developers and each team member has this ideology that everything is “just because of the way it is”. this can lead to a multitude of problems.

One of these problems is bad team building. When you assemble a team of people for some sort of project, you want to be able to work together to share ideas. If a problem arises you all want to be able to come together and understand what the issue is so you can solve it as a team. If you all think that things are just the way they are because they are, this can often lead to disagreements among team members. Some team members might even think you are against them just because you disagree with them on something. It’s this idea of confronting your ignorance that is vitally important to understand. You should learn one thing at a time, that way when a problem arrives, you can put aside  what you know, and focus on what you don’t know. Failure in a public place can be embarrassing, but it is exactly these failures that make it better. If you failed at something, you wouldn’t want to be ridiculed for it. Instead, you should learn from it and always be willing to learn more and more about the issue.

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