Posts

LEDs, Cars, Python, Euclid, Dogs, Cats, Karnaugh Maps, and Floating Points

Image
  Required reflections for week 1 CST-499 Software Engineering Capstone: 1) What project milestones did you accomplish this week? If you're working in a team, please list what you personally contributed, not the project status overall. This is an iframe into the page I'm working on right now: Well, I've been itching to get some programming done, my favorite activity, since before this program began - but I've been so busy the whole time, I feel like I've gotten even less time for programming now that I'm in a programming curriculum. This week in particular, I've been cramming at hard as I possibly can to get ahead in all of my tasks, which include both classes I'm taking, CST-499 Software Engineering Capstone, as well as CS-24, Elementary Computer Organization/Computer Architecture, at the junior college. In order to be able to get the time to begin the programming needed to complete my capstone project, I needed to do all kinds of stuff I wasn't...

Journal 77: Testing IS Documentation

Image
This journal's required reflection is to list the five most important things I learned in this course, (Java II, CST-438 Spring Boot Framework with React/Software Engineering at CSUMB) and why I chose them: Trunk based development in conjunction with Agile development is a correct paradigm, or at least a broadly applicable one. The reason is that I have discovered this on my own, in independent projects, and class material has reinforced this as being the paradigm in use by Google, and the paradigm Google engineers belive is most widely applicable. Spring Boot Framework with Java, MySQL and React using RabbitMQ for a service manager is quick, easy and a robust methodology to develop with. What we built has user authorization, a rich front end with easy build-ability, a MySQL connection with lots of database functionality automated for us because of the framework, and a back end built in Java with Eclipse which is pretty speedy because of all the auto-fill and problem checking Eclip...

Journal 76: Otters Have Lunch

Image
These pelicans use both Agile as well as Plan and Document methodology for catching fish for lunch. This week's assigned reflection is to compare and contrast the methodologies of Agile vs. Plan and Document (Waterfall). Plan and Document (Waterfall) is a process used for project management which focuses on the end product goals and the steps assumed that will be needed to get there. (ProjectManager, 2021) Agile methodology focuses on incrementally nudging features into a project so it's never broken, merges don't lose features, and everyone is working on close to the same code-base as often as possible. Plan and document methodology aims at a linear progression of adding features until the final product is finished, while Agile methodology aims at adding small cohesive features with correctness assertions backed by unit and end-to-end testing schemes. Plan and document is a tried and true methodology which would be used for things like government initiatives, where a speci...

75

Image
The important things I learned this week were many. We learned adding OAuth2 login to our Spring Boot Framework website to enable user authentication for the website through the Google login. We also reviewed an overview of Spring framework, adding front to back mods to enable the OAuth2 login with Google. The chapters we read in the book were great on encouraging effective collaboration, but I was not particularly a fan of the way chapter 2 started out by knocking independent effort. Google wouldn't be Google without Linus's operating system, Python wouldn't be Python without Guido Van Rossum, and one of the people reading the book is the creator of AccountBlaster , my favorite program of all time and also my own program, which I created entirely on my own. If it had been a corporate endeavor it would probably have been corrupted away from its true purpose. Being built in pure JavaScript and JQuery it is entirely a front end application running entirely at the client, with...

74

Image
Our required contemplation for the week is to compare and contrast unit tests with end-to-end testing paradigm: Post an entry to your journal contrasting unit testing with end-to-end testing. Unit tests go with each feature, documenting it and testing hopefully just it and as little other things as possible. Dependencies are mocked, faked and doubled and the unit test can pin the test to the behavior of only the thing it's trying to test. The purpose of unit tests are to not only make sure each feature works but to create a working example use to go with the feature, not only continually verifying the functionality but providing a window into what the expected behavior is if it breaks down. Database interaction is mocked, user interaction is mocked, just the logic in the feature being tested is under focus. The engineer that writes the feature is usually the engineer that writes the unit the test for that feature. End-to-end tests also provide a window into expected behavior bu...

73

Image
  First this week's required reflection: Rate the book "Software Engineering at Google"  1-best, to 5-poor  1.01 Rate the book "Full Stack Development"   1-best, to 5-poor  1.00 Why did you give those ratings? Software Engineering at Google is a (not so?) common sense book on broad methodology aimed toward specification of massive group collaboration giving adages for best practice and methodology in collaboration with large software projects that span through time across many different developers in long term cycles. One adage we learned right off the bat was that lots of small additions that work are a million times easier to manage than bigger, longer, more encompassing additions merged less often. I personally have found this true in my own projects, when I was a kid I started off the wrong way, building enormous projects that went nowhere - but I learned quick, and got past that, realizing what this book is telling us, incremental working stages are mu...

72

Image
This week's required contemplation: How does React compare to other frameworks you have used for front end development?  Well in 2010 I worked for a startup working out of the Stanford Library (literally, room 200) that used the Zend PHP framework for developing a career connections website. It was a mess - an utter mess - and inspired me to either write my own framework or to never ever use one. But React is totally different, it's cohesive, effective, logical and there's distinct ways to accomplish common objectives, as well as simplifications to common JavaScript, adding convenience. The only problem I have with React is the HTML stuck in the middle of the JavaScript. I think it should be JSON there, too, where the HTML is. JSON has just one label where HTML has two for each element, a lot less characters overall, and for that reason I find JSON superior in all respects and capable of housing the same data references as HTML does. I created my own framework I call WebBla...