During one of the last weeks I want to talk about what I learned throughout this senior design experience. I learned that it is very important to have good communication within the team. If you do not have good communication the amount of work can pile up as well as being focused on what you are good at is also important. Giving out ideas can decrease the amount of time it takes to implement something as well. This also goes a little bit into design. Talking through how you will implement something can create good ideas that will save time as well as making it known how you will implement something so somebody else on the team can make changes to it. Another thing that is very important is being accountable for your work. If one team member doesn’t implement something in the time he is supposed to, it could stall the other team members from completing their own tasks. Not only that but it could make things harder on other team members that are trying to get the project done. I think communication could solve this issue as constantly reminding them to finish their work is partly the whole team’s responsibility. There should be good motivation to do the work from everyone, but the team should help each other out as best as they can, as it is not only one person’s work, but everyone’s as a whole. I learned that relying on other people to do work that needs to be done before some of your tasks is a difficult thing to deal with. That’s why I think it is important to always have things in the backlog that you can do as well as lending a helping hand to be able to accomplish each task. Overall, It was a great learning experience that I will take once I join other teams in the future.
Author: Brian Kim
Blog post 7
This past week I have worked more with the communication aspect of our project. I have a decent understanding of how it is going to work, but there is a problem of being able to test the communication and especially commands with the actual wave lab. This is because we wouldn’t really know how to verify it is communicating with the lab unless we get in contact with someone on their end who is familiar with this sort of thing. From my understanding there really isn’t anyone with programming knowledge within the lab. We will have to speak with pedro to get that part figured out. Another thing that ties into that is the fact that we have to test the commands that are being sent to the lab. As we don’t want to mess anything up that will slow down the lab researchers, we would need a time slot to be able to test the commands with our web app. That could be a blocker as we don’t really know how open they will be in regards to testing and how often we can test our project. Other than that development has been smooth. I feel I can get my tasks done, but I might be waiting on other team members to finish their parts when it is all said and done. I believe we will need a little bit of time after the term is over to get everything to the point where we can deploy this and the lab researchers can use in replace of their old system. If we didn’t have to rewrite the legacy code I think we would have been done by now which is a bummer. I realized how important planning for these things is, even though it is nobody’s fault we didn’t see this coming. It is also a blocker that there is nobody that we can talk to if we have questions regarding the programming of the system because nobody is familiar with programming that we are working with.
blog post 5
This week has been very productive and the stress of the rewrite has lessened. We have most of the front end implemented, and the UI already looks pretty good when it comes to the water level history graph and the set water level aspects. The biggest roadblock however is yet to come with the valve communication as we don’t really have a full understanding of that aspect yet. Reason being, is the documentation on the legacy code doesn’t really point us in the right direction and we don’t have a good contact who knows how the system works. I am still confident the team will be able to push forward and get that working. We have the legacy code and will be able to get an idea about how the communication works, and since we got most of the other aspects done, we will have full team focus on the matter. The sites front end already looks more modern and sleek than the previous version, and while the backend is a question, we will just have to figure out how it will work. I feel a lot better about the project as a whole, and am really excited to get the full feature set working. After we get the communication and the proof of concept sort of working, we will be able to add a lot of cool ease of use features and have more free roam when it comes to what to add to the project to make it a better experience. Something that I have pushed for is SMS texting for updates about the wave lab. I think that will be a nice feature as the filling takes 8-12 hours in some cases which means the researchers won’t be monitoring it as intently.
blog post 4
This past week the team made the decision on whether or not to revamp the old system or not. We did go through with a total rewrite as we thought that the old system would take longer to add features to as the documentation was from 2014 and does not reflect the current system. Not only that, but we will have the freedom to make the software more up to date with current technologies. A rewrite also means that the team will be familiar with the entire codebase, and we will be sure to make the documentation thorough so that future teams will be able to work on the project and add new features. Due to a rewrite, we are pretty behind when it comes to implementation. We are focusing on a basic front end using angular so we can focus on inheriting all inner workings of getting the valve to open through our app. We will have to figure out a few major things that could become roadblocks through our development: communication with the lab, opening the valve through the national instrument labVIEW, and testing as the lab may not be very accessible. There are also things like login credentials, and security features that will be important once we make this app. We will also then have to deploy the app which shouldn’t be too hard but each step could create issues that might take a lot of time to resolve. At this moment the team is in medium stress mode but we are working hard to pump out this app as soon as we can. We have the basic implementation of the website done already, but we still need to add things to the front end. I think we may need some more time as the rewrite set us back as we were doing a lot of planning at the start of the term and designing as we thought we would only need to create the new UI.
blog post 3
This week we have faced some roadblocks with the existing codebase. We started our development and implementing new features but we were unable to build the project. The README documentation was very outdated and did not reflect some of the folders in the code we were given. There were also some syntax errors that even without these other issues would not allow for a successful build. We are at a crossroads where we feel we may need to remake the entire codebase into something of our own. We are currently weighing out the options, and I have contacted our project partner to see if he knows anyone we can get in a meeting with that could help us with the existing system. If not we may remake the project as that is seen to be less time consuming as we will need to roll this out soon. That process might be more time consuming as we will need to do more designing on top of what we have already done, but might be our only option if there is nobody that can help us. We will need to figure out how to communicate with the instruments and the computer that they use on-site. We will have to see how it will work out once our project partner responds to us then we will have to make a fast decision on our path moving forward. This week has shown the most roadblocks so far with our project, and has caused some stress within the team. I however am confident we will work past this roadblock and be able to finish the project on time. I have created an application for a similar use case so a remake will allow for us to design something we are comfortable with and have experience in using when it comes to libraries and tools.
Blog post 2
This last week we have made and mostly finalized our final design for the website. It includes, and mainly focuses on responsive design for mobile phone screens. The initial want from the project partner was to have a dedicated mobile application, but the main focus was to have a site that is compatible for mobile phone screens. He also stated that having a better screen that uses the same web app system would also suffice as the UI is not very mobile phone friendly. As a team we weighed out the pros and cons and contacted the project partner and said that having a mobile app could have a high ramp up time as we would need to have two implementations for it, IOS and android as they don’t share the same programming tools. This would free up time to do other things that would make the website more usable than an app that we would have less time to spend on. He agreed that the system is more for utility and the fact that having two separate mobile apps could take time away from implementing other, more important changes should lean us on making the website better. This will allow us to implement new features that wasn’t thought out during the planning of the project, that will make the web app more better. We thought of using mobile sms notifications that will send to the lab researcher once the filling is over, or even progress on the filling. Things like that will make the system more robust and polished. We are finally working on the implementation after all the designing and preparation and I’m excited to see what the team can accomplish with this time, and our goals concrete.
Initial Blog Post
The start of the term has been going well, and the change from online classes has been easier since i’m more used to it. I will be doing one more MECOP internship from the summer until fall term ends than one more term until I graduate. It doesn’t seem that long ago since I started at OSU as a freshman and I have learned a lot of valuable information throughout my years here. Not only did I further my education, but I was also able to grow as a person and adult by being more responsible and more acquainted with things. While I wish the last year of college could have turned out differently, it was still a great overall experience and one that will hopefully set up the rest of my life. I landed my first internship through the MECOP program last year and coupled with my classes it has made me feel prepared to work in this field. I understand more about what it means to have a highly technical job, and what that comes with. I also learned that since a lot of engineers will have to talk to people that are in different disciplines, learning how to teach people to a certain extent is also key when communicating with people in the company. I also understand that I don’t need to necessarily know the ins and outs of a job, but that being a hard worker that is constantly learning and evolving will help my growth as a professional. It has given me a lot of confidence knowing how much I have learned so far that I could do anything I want post college. I feel hungrier than I ever have before to be a professional and start the rest of my life and coming to OSU has definitely helped in that regards.
Week 7 blog
This week I wanted to do some research on potential technologies that could be used within our Hinsdale Wave Lab project. As I am tasked to handle the lab computer aspect, I did some research on National Instruments labVIEW. The research consisted of some documentation and YouTube videos to get orientated with the software. It seemed pretty straightforward as the library is programmed to be used on the specific instrumentation. I still need some familiarity with the software, but it shouldn’t be too much of a hurdle at this point. I also looked at some xCode and swift programming. I am used to android studio and making apps for the android platform, but there are a lot of high level similarities between the two and it has great documentation and youtube tutorials. It helps that IOS developing has been a trend lately and a lot of people are doing it. Earlier in the week we worked on the group team design document. It will serve as a living document that we will look back on when developing the system. We need to make sure each part is implemented, and that it meets the standards of our project partner. I’m sure the document will change over time as our needs are shifted, but for the most part everything should follow the design document. We may switch technologies used if we see a better fit for our application, but that’s about it. Now, I am just excited to start developing the system as I feel like we only have a little bit more research to tackle this problem. This project as a whole feels a lot like my internship last summer, which was when I learned the most about being a software developer. I hope to learn a lot during this project to take it into my future projects and tasks.
Blog week 6
This week I looked into a few potential technologies that could be used with our project. First off, I looked at some beginner IOS development tutorials as I am more familiar with android studio and would need to learn how to make apps on that platform. It was very interesting to see how apps are built on IOS. It uses its own swift programming language. Swift is a compiled general-purpose, multi-paradigm programming language that is expressive and concise. The other thing I researched this week was writing simple code. It is important to keep your code simple without extraneous code that you do not need. Making it simple not only make it better for scalability, but it is easier to understand from another developer who didn’t work on it. If you have extraneous code or duplicate code, it could make developers wonder why that is there before they realize you do not need it. In code, everything should be designed that way for a reason, so it makes other developers question why that is there before it is obvious to them. Simple code will also cut down on development time and the design decisions will be specific making you think about the design more. My last internship we worked a lot at refining the code that we have, constantly refactoring to make it as simple as possible. All of the code in the system should be there for a reason, and if you decide on implementing it another way, the old implementation should be deleted. Throughout the development process, you should always look back and see if there is a better way to implement that is more intuitive. Chances are, the first time you implement something that you are not familiar with, there will be refactoring needed. Once you become familiar with technology then it will be easier to get it right the first time, but otherwise, there should always be room for improvement and simplicity.
Blog week 5
This week we worked on the technology review assignment. The assignment consisted of explaining the parts of the project I am assigned to, and research technologies to accomplish those parts. The parts of the project I am assigned to are lab computer-specific tasks that consist of the lab computer Python script, the lab computer commands to instrumentation, and the lab computer communication layer. Firstly the lab computer script technology is going to use Python as the National Instruments library is in Python and it is generally easier to code things that only require a small codebase to work as needed. The next technology pertains to the lab computer commands. This uses the National Instruments LabVIEW to facilitate communication with the filling valve at the Hinsdale Wave Laboratory. There is no other technology to use as it is proprietary. With that being said, I have used National Instruments libraries before to communicate with instrumentation so I feel like it would be a smooth implementation that I foresee no problems with. The last technology I mentioned is using sockets to communicate with the clients. Our architecture consists of a mobile application client that will communicate with a server to then relay that information to the lab computer that is connected to the filling valve and pressure gauge. Messages will be sent back and forth from each client, and sockets are our first choice for the communication layer. I chose this because there is a lot of documentation and it is the fastest possible communication method available. There is still research being done on other methods like MQTT, which doesn’t share the same performance, but for our application, it may not be needed. This week has gone smoothly, and I am excited to start implementation for our project. It will definitely improve the efficiency and experience of lab researchers at the wave lab and hopefully, improve learning and research.