Previously, in Part 2, we went over Git Branches and the HEAD. Let’s continue by starting off with Remotes and how to get your stuff to other developers or into a project.
Follow DISTek......
Previously, in Part 2, we went over Git Branches and the HEAD. Let’s continue by starting off with Remotes and how to get your stuff to other developers or into a project.
When creating an application, one of the most difficult aspects is choosing a language/framework that will meet all requirements. The VT Anywhere team has learned this first hand, hence the title of the application VT Anywhere. VT Anywhere is split into two parts: User interface and Server. The languages of choice are JavaScript and Rust respectively.
There are tons of tutorials out there that show how to use Git, starting with easy things like cloning a repository and committing locally, then pushing your commit to the server. There are lots of sites and videos that will help you achieve a competent level of Git expertise - like this one. However, you may struggle with the interface and if you have problems, you may struggle to understand why and how to fix them. That is why I am going to explain Git this way: inside out, backwards and hard. This three part series is targeted for people who want to excel at using Git and deeply understand it. This is also intended for people who are willing to persevere a bit more than the average person. Lastly, this is for people who like to see the beauty in things and, trust me, Git is beautiful.
Eliciting a set of user stories can be a challenge when stakeholders are not sure where to begin their description of the solution they require. It is often up to Requirements Engineer (RE) to guide the stakeholders along in assessing the problem in need of a solution, as well as assessing the best solution for the problem. The RE must further help the stakeholders partition the solution’s description into manageable tasks, and express those tasks as User Stories. Workflow Driven Elicitation (WDE) is a systematic approach that helps achieve all of the above.
In my personal projects, I often work with various sensors which require digital data verification. One such sensor required the use of a Cyclic Redundancy Check (CRC) to verify that the information that the micro-controller read from the sensor was being received correctly. A CRC is a method for calculating a checksum from an array of data. The software examples that I was able to find to develop my understanding of implementing a CRC were poorly documented. Moreover, these examples were often so optimized that the underlying behavior was not immediately recognizable. Many examples simply used a lookup table---which provided no satisfaction for my "what-makes-it-tick?" personality.
Share this post with your friends.........
Follow DISTek......
Here at the DISTek products department, we're always looking for ways to make our user's lives easier. As engineers that use our own products, this is doubly important to us! We've identified that open source tools can be one possible solution to alleviate potential issues down the road.
We spend a lot of time designing user interfaces for ISOBUS VT clients. There are a few tools currently on the market, and while these tools get the job done, we've found a few shortcomings...
Share this post with your friends.........
Follow DISTek......
Safety is a challenging status to achieve and maintain, thus the need for the guidelines that collectively fall under the heading of Functional Safety (FS). DISTek has always been conscience of safety as it applies to the products developed for our customers. This includes implementing the various requirements and guidelines associated with Functional Safety, as expressed in documents, such as ISO 25119.
Share this post with your friends.........
Follow DISTek......