Category Archives: CS443

Wednesday, 29 March 2017 Sprint 4

Since Spring break was last week I did not focus much time into experimenting with the NGModel. I hope to continue more tutorials to try and apply the NGModel to our issue. Tyler and Dan have reason to believe that we are looking at this issue all wrong. We have many theories yet no real solutions. We noticed that the request respose is what we need to investigate to get an idea of what the code may look like as well.

This has proven to be slow moving but learning a whole lot about angular and other JS tools.

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 7: Wednesday, 8 March 2017 Sprint 3

We have finally reviewed and selected our Issue. NGPOC-185, this issue essentially is that we want the user to be able to log out but if they are editing a form then they must be prompted to exit without saving the form data or to stay at the page and continue their work.

We are not sure yet how this should work but we know we must use the Materialize CSS library since the interface for Ampath is made with this CSS package. This issue could also involve detecting if a user has ‘touched’ the form. This is a feature of the NGModel: This allows angular to detect if the form is ‘dirty’  been changed, ‘touched’ if it was edited but not altered. and ‘untouched’ if the user did not touch the form yet. Looking forward to seeing how to implement this models capabilities.

We have decided to regroup and collaborate our ideas that we may have found towards this idea. We do not fully understand the project structure so this may take some time.

 

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 6: 23rd February – 30th February

This week we have finally connected with our Project admin Johnathan Dick. We are now added to the Ampath Jira software, it is great to be exposed to these issue tracking and continuous integration tools such as Travis CI. We need to connect to the test server they have set up so we can have some data to play around with in the Ampath application.

Looking forward to starting work on some issues

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 5: 15th February – 22nd February

This week has been slower than last week. I have rewritten the authorization module, yet I feel as though I am copying and pasting their code. It is a simple module that really has the imported Open MRS Auth. Module to do the heavy lifting and take care of the passing of credentials. This leaves the routing and the request observer for login. None of this code is really changeable so I am hoping to dive deeper into the core of this application. Class has been slow moving at this point, but we are reviewing angluar 2 issues, tutorials and development in general.

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 4: 7th February – 14th February

This week was more exciting since we began to work with Open MRS AMPath. Building the project was like any other node application. In the terminal, I navagted to the root app folder and used “npm install”, and “npm server”. This started the ng2amrs test local server and was easy to log into. It seems you can not halt the server forcfully or you will not be able to restart it unless you reboot your machine. I have watched hours of Scotch.io tutorials and look forward to rewriting the Authorization Module. It does not seem complex since they import the OpenMRS authorization Module making the hard work already complete.

Let see what this next week brings!!

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 3: 31 January – 6 February 2017

This week was a slow week out of the semester since we were finishing our tour of heroes.

We have learned a lot about routing, two way binding and the nifty features angular provides. It is sad to note that Angluar does not have a built in sorting algorithm since it added complexity and making a flexible application framework requires light weight and freedom for developers to implement proper efficient algorithms for their use. This is kind of a cop out yet shows that every developer should know how to make efficient sorting algorithms for their programs.

Looking forward to working on Ampath.

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Ch. 3 and Ch. 4

For this post I read chapters 3 and 4 out of Sandro Mancuso’s The Software Craftsman.  In these chapters Mancuso breaks down what he means by Software Craftsmanship.  First and foremost a Software Craftsman is a professional who is constantly learning new tools and techniques.  In chapter 3, “Software Craftsmanship,” Mancuso presents and explains the Software Craftsmanship Manifesto:

Not only working software,
but also well-crafted software

Not only responding to change,
but also steadily adding value

Not only individuals and interactions,
but also a community of professionals

Not only customer collaboration,
but also productive partnerships

The second piece of every part of the Software Craftsmanship Manifesto simply elaborates on the first piece.  This is very different from the Agile Manifesto which contains contrasting ideas.  In this way, the Software Craftsmanship Manifesto seems almost intuitive.  For example, take the first piece, “Not only working software, but also well-crafted software.”  The next logical step from working software is software that is well put together.  In TDD after you write a test, you write code that makes that test pass. Then you write another test, and more code to pass that test.  Refactor and repeat.  Using this technique you write not only working software, but as you progress, the software becomes well crafted.  So I guess I can understand someone feeling as though they need to lay out these guidelines, but as these techniques have developed over time, the aspects of the Software Craftsmanship Manifesto seem almost inevitable.

Chapter 4 is entitled “The Software Craftsmanship Attitude.”  This chapter is essentially a recap of The Clean Coder in its entirety.  Instead of going through all of the content of this chapter, I would like to refer you to my previous posts.  After reading this chapter, and without having read the rest of this book, I would think that simply reading this book would cover most of, if not all, of the pertinent information from Robert C. Martin’s The Clean Coder.  I think that the overlap is probably pretty substantial.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Ch. 1 and Ch. 2

Fitting that the last chapter in Robert C. Martin’s The Clean Coder was about craftsmanship, now we are reading The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso.  I’ve read the first couple of chapters of Mancuso’s book and I’m not sure if I like this book any more or any less than the previous one.  I suppose that is fortunate.

The first chapter was titled “Software Development in the Twenty-First Century” and this chapter is about as long as the title.  Chapter one was all of six pages long and served only as an introduction to the rest of the book.  Mancuso did discuss the idea of seniority in the field of software development and broached the topic of Agile, the topic of the next chapter.  There wasn’t really enough content to reflect on this particular chapter.

Agile!  I love it, I LOVE it.  I’ve read and heard so much about the Agile process in the past year, and aside from the fact that its the direction businesses are moving, it just makes sense.  I’m pretty sure I have blogged about Agile before, but if not, I’m happy to do it again.  Most importantly we need to include the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This is just a better way of handling projects.  Using an Agile framework, ie. Scrum, and keeping in line with the Agile Manifesto companies are able to produce software more quickly and with better quality.  Agile reduces errors, misunderstandings, and obstacles by introducing more communication.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

The Clean Coder Ch. 13 and Ch. 14

This week I read the final two chapters of Robert C. Martin’s The Clean Coder.  These chapters were not very long and only covered a couple topics.  In fact I only took away two points from chapter 13 on “Teams and Projects.”  These two topics were on the “Gelled Team” and “Velocity.”  A quick overview on Martin’s “Gelled Team” is a group of about twelve programmers, testers, analysts, and one project manager, who have worked long enough together to develop a symbiotic relationship.  I have worked closely with a few students during my time at WSU and we have certainly developed something close to what Martin described.  I know how these students think and work, and it aligns well with my process.  Martin describes “velocity” which my group and I have been experimenting with and adjusting as we figure out how much work we can accomplish over our sprints.

Chapter 14 was entitled “Apprenticeship, and Craftsmanship” which focused on the idea that school does not prepare programmers for the field.  To be honest I am concerned that I have not accrued enough knowledge to be an effective programmer in the field.  Martin suggests a system in which there are Masters, Journeymen, and Apprentices, where the more experienced teach the less experienced.  I like this idea, where for the first year, the Journeymen teach the Apprentices, and over time the Journeymen become Masters who orchestrate the entire process.  Martin also discusses the idea of Craftsmanship, which he calls “a mindset of values, disciplines, techniques, attitudes, and answers,” which are handed down from the experienced to the inexperienced.

Well that wraps up, The Clean Coder.  Stay tuned for more posts starting next week on a whole new text!

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

The Clean Coder Ch. 11 and Ch. 12

Another week, another two chapters from Robert C. Martin’s The Clean Coder.  This weeks installment were chapter’s 11 and 12 which were entitled “Pressure” and “Collaboration” respectively.  They combined for eighteen pages of fluff.  Each contained the signature Bobby Marty anecdote which ate up a large portion of both chapters.  In my last post about The Clean Coder I said that I was starting to enjoy his chapters.  I guess I spoke too soon.

So chapter 11 was about pressure.  Martin writes about avoiding pressure and handling pressure.  I found it interesting that Martin thinks maintaining discipline is both a way to avoid pressure and to handle pressure.  He uses TDD as an example.  The problem with TDD is that it is time consuming.  Not only do you have to think of the code you need to write, but you need to write tests that the code will eventually need to pass.  This means that you will be writing twice as much.  His idealistic position on deadlines is unrealistic.  Sometimes you need to make adjustments in order to make deadlines, and in those cases, disciplines must adapt.  TDD may be the best way to do something, but sometimes sacrifices must be made.

Chapter 12 was about collaboration.  It is asinine to resist collaboration for the greatest accomplishments have not been achieved by a single person, but a group of people.  The overall message of this chapter is that working with other people is important, and I don’t think that many people would disagree with that.  I found his section on cerebellums to be superfluous and poorly labeled.  Cerebellum has very little to do out of the context of that billboard he read, and thusly carries little weight outside of that chapter.  I also found that his take on collective ownership interesting.  I feel as though it needs a qualifier.  Collective ownership is certainly the best way to go, IF and only IF you can trust the people you are working with AND you are using a version control system.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.