Week 7 Thoughts and Experiences

Work

This past week was one of my more productive weeks thus far this summer. I will do my best to summarize how I spent each day.

Monday:

• Blogged
• With Joe's help, I was able to successfully test and verify changes I made last week. These changes included tweaking the "Manage" buttons on the Sentinel home page to only appear if the user has permissions to use them.
• Sifted through the Sentinel home page, finding all of the links on the UI that still needed to be utilizing the "smart_link" or "smart_url" functions in order to only give access to users with valid permissions.

Tuesday:

• Began by explaining to QA how my FTP Setup Tool changes were, in fact, behaving correctly. (My bad QA guys for not explaining more clearly.)
• Successfully finished tracking down the file/code for all of the millions of links, buttons, and clickable graphs on the Sentinel home page and implemented the permissions.
• Pull Wholesaler Invoices button -- Previously, TA's had to find someone to pull invoices manually if they have invoices >3 months old when they were ready to allocate. I modified the button to also pull in invoices older than 3 months.

Wednesday/Thursday:

• Modified the _build_query_and_params() function that constructs the query string corresponding to the filters used in the 'Item Mapping' tool. Modifications included 1) restructuring, 2) trimming the leading and trailing whitespace from a search string, and 3) making the search by NDC look for ALL mapped drug equivalents. Previously, the search returned only CDMs that had, as their primary mapped NDC, the NDC that was being entered into the NDC search filter. Now, the search returns any CDM that contains, as any of its mapped drugs, the NDC that was being searched for.
• Collaborated with Robert "Bobby" Long on the "Matrix Performance Report."

Friday:

• Took out the "Shared Key" column from the VPN reporter and replaced it with a Client Name column. This required adding to the the query in VpnSetupManager::get_vpn_list() to return client_name from freedom.client. Changed default rows displayed from 100 to 250.

Fun

My younger brother, Luke, who just graduated high school and also will be attending Purdue in the fall, called me on Thursday night around midnight. He explained that his friend was making a trip from Indianapolis to Orlando and that he was offered a free ride. Luke had originally hoped to come visit me this summer, but with the help of the parents had determined that impending college tuition rendered him financially incapable.

However, with this new transportation breakthrough, visiting was again an option. As it turned out, the friend was leaving Indy at noon the next day (that's right, twelve hours later). I hurried and hooked Luke up with a $25 bus ride from Orlando to Pompano, and Luke was in town by Saturday afternoon. Saturday we went to the beach for several hours and played volleyball and frisbee and tossed some baseball and football. We also went out to eat at Whale's Rib, a seafood restaurant just down the road from my apartment. Sunday we went to the church that I have been attending, Boca Raton Community Church, and then I had a YMCA basketball game with some of the Sentry guys. Luke ended up being able to play on our squad as well. Needless to say, our team, virtually a man amongst a league full of boys, dominated again, continuing our undefeated season.

After basketball, we had a tee time at Deer Creek golf course. I upheld my big-bro dominance and handed him an 89-100 loss, 2nd career Eagle and 1st career back-to-back Birdies in tote! Monday I took a half day so that we could make the most of his two-day visit, and we went golfing again, before hanging out with friends. I shot my best career 9-holes, a four-over-par 40. Monday night I drove Luke to the West Palm bus stop, and that was the end of his all-too-short stay in paradise.

Week 7 Reading Response

Peeblogs:

Despite the quantity of this past week's Peeblogs, I came away with only two "diamonds in the rough." (Keep in mind that this is likely due to my terrible memory, not due to the scarcity of diamonds.)

"You can delegate authority, but not responsibility." For example, when a manager learns from a customer that something does not work correctly, he can then go and assign the project of fixing that problem to one of the employees that work under him. He has "delegated authority." However, despite the face that he has put the employee in charge of the project, he is still responsible to the customer for the project being completed and fixing the customer's problem.

"Every startup has to have several early heroes." Peebles explained how the company would never have stayed afloat if it wasn't for the "early heroes" of the company going above and beyond the call of duty, putting in extra time and effort to jumpstart the company. These same heroes have also been turned to in times of company-crisis....they are the saviors of Sentry Data Systems!

"Code Complete"

Let's just say that Code Complete is no more "complete" than it was last week...

Other:

One vital skill that I believe can be vastly improved at Sentry Data Systems is the art of "ticket writing." I cannot begin to explain the countless hours that I have wasted attempting to problem solve what the description OF a ticket means before I am able to actually start solving the problem described IN the ticket. Four specific areas where ticket writing can improve are the following:

• Laziness: The #1 problem that I have encountered when reading tickets is epic proportions of LAZINESS! It is clear that the majority of so-called "ticket-authors" are in a rush and consider writing tickets to be a completely boring and meaningless task. They refuse to describe WHOLE problems and use vague terminology, clearly maintaining the opinion that it is better to waste their reader's time and, in turn, waste their time by causing him/her to have to ask thousands of questions.
• Location: Please CAREFULLY and DISTINCTLY specify the location within the UI of the problem that is being described.
• Clarity: When writing within a ticket, avoid using vague terminology. Go above and beyond the call of duty to explain the problem and/or method of solution.
• Problem/Functionality Definition: Describe, in detail, the problem AND how its behavior is wrong. Describe the correct functionality of that problematic item so that the ticket's reader can formulate a solution that brings that functionality to fruition.

Week 6 Thoughts and Experiences

Work

This week was mostly productive, though, as does any week in the life of a developer, it contained several snafus that made projects take longer than they should have. I suppose that I am more prone to this than the more seasoned employees here at Sentry, but I also learn a lot when solving these issues. I will now give a brief summary of this week's work.

On Monday I began by finishing up my first unit test. I had a couple issues left over from Friday that I had questions about, and Joe Heth proved quite helpful in dealing with them. Finishing the unit test FINALLY allowed me to commit the changes that I had made to the Search/Audit Tool. I also did some blogging.

The rest of my week involved three more "commits" and almost a fourth:

• VPN Setup Tool -- I edited this tool to allow Implementation to have read-only access. This involved disabling all of the fields and hiding all of the links for Implementation users.

• FTP Account Tool -- This tool was edited so that Implementation could not modify an existing entry's Account Name, SFTP toggle switch, or affiliated VPN Tunnel. This seems easy, but it proved quite difficult, as I could not just disable each of these fields. Disabling the fields resulted in the values in those fields not being passed when the form was submitted. Joe and TVR helped me find a tricky javaScript solution to this problem.

• Pyxis Feed Editor -- I added a 'Paranoia Alert' radio button and 'Paranoia Alert Comment' text field. This involved adding support for the two new fields to the SourceFeedDAO.php object.

• Sentinel home page widgets -- There are a number of widgets that link to different parts of the system. Thereare several "Manage" buttons that are directly linked to pages andignore any permissions. I am working to allow those buttons to be visible only to users that the buttons will actually work for. (Previously we just sent the frustrated users back to the Datanex home page when they did not have permissions to click the button) This is proving to be a little harder than it should be, as I had to add some functionality to the smartURL function and am having trouble finding users to possess so that I can properly test if my changes are functioning correctly.

Fun

The past couple weeks, I had three visitors! My brother Zach and his wife Megan visited for a week, and then my sister Rachel also visited for a week. Needless to say, our one-bedroom apartment was pushed to its limits, but, thanks to our pullout couch, a newly purchased air-mattress, and accommodating roommates, the visit was a success. We went to several awesome restaurants, including Old Key Lime House, which is supposedly Florida's oldest waterfront restaurant. I got a Mahi-sandwich, which was quite tasty! Zach and I went golfing at Palm Aire Country Club's "The Oaks" golf course where I didn't play particularly well, but shot a 92 and still managed to beat my big bro who was using unfamiliar, borrowed clubs. We did lots of other fun stuff, but I am going to stop here, as I would like to begin Week 7's work.

Week 6 Reading Response

Peeblogs:

This week's Peeblogs will be heavily dominated by several words of financial advice, but first, a quote from The Man himself,

"Don't focus on why you can't do something. Focus on what needs to be done, and find a way to do it."

Financial Principles:

-- Live 2-3 pay-cuts lower than what you make.

-- First priority after graduating college is to construct an emergency fund equivalent to 6 months of your salary.

-- The two most important financial decisions you can make are marrying a frugal woman, and never getting a divorce. (addendum from Troy, "Don't get married.")

-- Bonuses should NEVER be counted on when budgeting.

-- Setup student loans to be paid automatically, as missing a payment kills your credit score.

-- Pay debts in order of descending interest rates.

-- Pay the minimum on loans that have a lower interest rate than the rate of inflation.

-- Sign up for zero tax exemptions. This guarantees a large tax return check and assures that you will not have to pay any money back to the government.

-- When debating between using money to pay off a loan or using it to invest, the following formula applies:

LoanInterestRate - RateOfInflation = WorthwhileMinimumInvestmentReturnRate

"Code Complete"

I began reading "Code Complete," by Steve McConnell. This week I read the preface, chapter one, and most of chapter two. Yeah, pretty lame...I will try to do better this week. The following quote explains why Code Complete is applicable to me, "The recent graduate is often rich in theoretical knowledge but poor in the practical know-how that goes into building production programs. The practical lore of good coding is often passed down slowly in the ritualistic tribal dances of software architects, project leads, analysts, and more-experienced programmers. Even more often, it's the product of the individual programmer's trials and errors. This book is an alternative to the slow workings of the traditional intellectual potlatch....It's a hand up for the student making the transition from an academic environment to a professional one."

Week 5 Reading Response

In order to uphold tradition, I will be beginning this post with this week's all-famous Peeblogs. Unfortunately Mr. Peebles was abroad for the majority of the week, so Peeblogs were few and far between. However, despite the scarcity of these little nuggets of truth, I still managed to garner just a few:

--It is very difficult to implement a system that regulates employee promotions and bonuses accurately. This is primarily caused by what Sir Peebles referred to as "optimizing to the metric." In other words, if you setup a metric that is supposed to measure how much an employee has accomplished, that employee will always pay extra-special attention to that metric, making sure to go "above and beyond the call of duty" in the specific area of that metric. This makes it seem that the employee deserves a raise or a promotion, when, in reality, they have merely "optimized to the metric."

--It is quite common for an employee to be promoted to his "highest level of incompetency." This results from the employee working his way up the career ladder, earning rightful promotions until he eventually gets promoted to such a high position that he is no longer competent to do his job. The employer is then faced with a dilemma. Should the employee continue to underperform in his current role, be demoted back to his highest level of competency, or be let go?

--The corollary to the previous point is that managers must think very long and hard before they promote an employee. Demotions are rarely a feasible option, as it generally leaves the employee dejected, dispirited, and embarrassed. Promoting an employee too far is a good way for a company to lose of its most valuable and successful workers.

Moving on, week 5's assigned reading involved three articles on unit testing, which were helpful, because I ended up spending the majority of Week 5 writing my first unit test. I will touch upon each of the three articles briefly.

Article #1 was entitled "Why are we embarrassed to admit that we don't know how to write tests?" It's author drove home the point that "The secret in testing is in writing testable code!" He gave several practices to avoid in order to write code that can very easily have unit tests written for it. I will now quote his second point, which I felt was his best comment in the entire article, "The developers are where the mistakes are made, and testers are the ones who feel the pain. Do you think that the developers have any incentive to change their behavior if they don't feel the pain of their mistakes?" I feel that Sentry addresses this issue by requesting that the developer also be the one to write a corresponding unit test for his own code.

Article #2 was "The Advantages of Unit Testing Early." Three advantages that stood out to me:

Instantaneous Gratification-

-Writing a unit test as you code or even before you code allows you to test a small component of a larger application that has not yet been completed.

Refactoring Safety Net-

-Having a pre-existing unit test allows a developer to refactor code and then check to make sure that he did not break anything.

Documentation-

-Unit tests can be used as a reference to find out what a particular method or class is supposed to do and how.

Article #3--"How to Write 3v1L, Untestable Code." This last article was a blend of poorly written and hilarious. The author decided to turn his blog into satire, writing from a purely sarcastic standpoint. I couldn't have agreed more with one of the readers who aptly commented that, "While the content of this post was excellent, the disingenuous, sarcastic, say-the-opposite-of-what-I-mean style of it was a complete turn-off. I hope you consider re-posting this information in a positive, "what-to-do" style, so that people don't have to parse through all of your negations just to get some good tips." The principle that hit home for me was that I should not use lengthy/intricate if-branches. I have a nasty habit of doing such at school on projects that are merely tested for functionality, and this was a good reminder to break such a habit. I will let points #2 and #3 speak for themselves as they are quite comical and will allow a small glimpse of the sarcastic style of the article:

"Macros are your Friends - Always use #ifdef PROD and other compile-time switches to make sure the testies can't get at your really important blocks of code and test them. In fact, this code won't even run: until it gets to production!"

"Final Methods - Use final classes and methods all the time. They can't be overridden for testing (-; But don't bother making fields final, or using value objects (without setters) - just let your objects' state be changed by anything and anyone. No sense in guaranteeing state, it'd make things too easy."

As parting words of hope, I would just like to let you know that it is merely Monday, and I have already acquired useful material for next week's Peeblogs!

Week 4 Thoughts and Experiences

Just as with every other week here in SoFlo, this one has flown by. I don't have any new, exciting experiences to add to the list that I started last week, so I will skip that section until (hopefully) next week. I will jump straight to the work that I have done this week here at Sentry.

Wednesday marked a milestone in my time at Sentry thus far. My mentor, answerer of every question that my brain can possibly come up with, and endless pool of knowledge, Joe Heth, began a week-long vacation. Do not get the wrong impression, this was not a milestone because Joe Heth took a vacation, rather, it was the first time that I attempted to walk around on my own two wobbly legs without Joe there to give direction. Liken it to a child taking the training wheels off of his bike for the first time. I spent the remainder of the week on a ticket that originally involved just making the Audit/Search tool's "Details" link point to its corresponding invoice instead of its purchase order. However, as I dug deeper into the cause of the issue, more and more errors became evident in the tool's design, and those whom I consulted instructed more and more changes to be made to the tool. In the end, I was doing pretty much a full revamp of the entire invoice feature of the tool. This primarily involved working with Jay Ohms to tweak the InvoiceManager object that he was in the process of creating. After a lot of communication back and forth, we have succeeded in providing a function in his object that returns all of the necessary elements for my reporter object. I made the following modifications to the Invoice report:

--Originally the user could choose between searching from "All Invoices," "340B Invoices," or "Non-340B Invoices." Separate reporter objects were extending a parent reporter object and being used to display the 340B and non-340B invoices. I combined these two objects into the parent object which they formerly had been extending, eliminating the necessity of the two "child" objects. Both types of invoices are now displayed in the same report with a new column called "Order Type" that distinguishes whether an invoice is "340B" or "Non-340B."

--The speed is optimized due to not using binding for $site_id in the SQL query. It is also optimized as a result of Jay writing a more efficient query that eliminated the need to look in any cardinal tables.

--The "Details" link no longer exists, but its functionality has been replaced by making the invoice number into a clickable link.

--The expandable rows feature has been done away with.

--When searching for invoices by NDC, the drug count number actually displays the number of different drugs in the invoice, rather than always displaying "1" like it did before.

--The report is now default displayed as sorted by date in descending order.

--All rows in the report display invoice numbers. (many did not previously)

--All results displayed in the report now match the search string. (Many times invalid results were previously displayed or not all of the correct results were displayed.)

--Invoices with a common PO# are displayed, rather than just displaying one of them.

That pretty much sums up my week of work. I have been talking with Cyrus, Ben Mahan, and JJ Foote about a few more modifications which I feel would really improve the functionality of the tool for the user, and I will likely be presenting a mock-up of what the UI will look like in the upcoming week. Other than this ticket, I also teamed up with QA to solve an issue in one of the tickets that I had submitted last week, and I began working on another ticket involving the Drug search option in the "Search/Audit" tool.

Week four makes me feel like I didn't get a lot done, just because I didn't close any tickets, but, now that I've written everything down, I feel a little better about my accomplishments.

Week 4 Reading Response

Before touching on this week's "official" reading assignment, I am going to reflect upon a couple less official, yet, no less educational experiences. Some might call them "Choctaws," others might refer to them as rants, still others might call them "Soapbox Specials," however, I choose to label them "Peeblogs." That's right, educational, hysterical life experiences and musings by none other than your very own John Peebles. During this week's near-daily Peeblogs, I learned the following very important principles:

• It is key in life to have the ability to take that which you learn/hear/read and be able to apply it to, and associate it with, the real-life situations that you find yourself in everyday.

• The three most important life skills are:

1. -Writing
2. -Reading
3. -Being able to conduct yourself according to the surroundings that you find yourself in, so as to make a good impression and establish good standing. (i.e. People skills in any situation)

• In order to be great, a man must read no less than one book per week. As a result of this principle, I have begun attempting to teach myself how to speed-read, according to an article on the Internet.

• Companies' incentive plans, when regulated poorly, can actually end up demotivating their employees. Sir Peebles went on to explain how his friend had quit working for a company because they denied him his $20k bonus, which resulted in the company losing one of its best employees to a staunch competitor. He explained that, in the long run, the company was ruining themselves. He followed this story up with what was by far the best analogy that I heard all week: "You end up plugging a grenade up your ass. Sure, it feels great until it goes off, and then you're screwed."

And now on to this week's official reading assignment, "Continuous Integration," by Martin Fowler. Fowler's article was an outright home run, endorsing and explaining the ins and outs of CI and hitting upon the principle from every angle. Here is a brief synopsis of what I took from the article.

In CI, "everybody develops off of a shared stable base and never gets so far away from that base that it takes very long to integrate back with it. This results in in less time spent trying to find bugs." Every developer keeps and maintains a copy of the current integrated source on his machine. Updating this copy is called "checking out." This copy must stay up to date with the mainline, or, current source code. In short, there is a single source repository maintained by a program such as Subversion, which contains all of the source code for the product/system. When a developer wants to edit some of this code, he makes sure that he has an updated copy of that source code on his own machine and then works with that copy while editing and initially testing. Eventually, after extensive testing, that edited code will be integrated back into the mainline using a continuous integration server such as Cruise Control.

The following are a few important practices in CI:

• Maintain a single source repository: A mainline with very few branches, which might be necessary for bug fixes and temporary experiments.

• Automate the build: Everything should be able to be built/linked by issuing one single command.

• Make the build self-testing: A close runner up to the above-mentioned John Peebles quote: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all."

• Keep the build fast: Make the build staged: a "commit build" that should quickly test a large amount of the code and a "secondary build" that runs some of the more time-consuming tests. The following is very important in regards to creating an optimally staged build, "As much as possible you want to ensure that any secondary build failure leads to new tests in the commit build that would have caught the bug, so the bug stays fixed in the commit build. This way the commit tests are strengthened whenever something gets past them. There are cases where there's no way to build a fast-running test that exposes the bug, so you may decide to only test for that condition in the secondary build."

Until week five, that is all I have for you. Come back next week for more Peeblogs if you dare.