In light of what happened last week, I decided to make coming up with a strategy for backup a priority on the Massachusetts HOSA website. After all of the work that I put into the design the first and second time around, I do not want to risk losing it again. In many regards, I am thankful that losing the data happened when it did. It has allowed me to improve my habits and develop in a more efficient and sustainable way.
The first thing that I made sure to do once I had restored the design of the website was to make an initial back up of the files and database. Although there are more efficient ways (I’ll explore some of these later), I chose what was easiest at the time and copied the files from the web server to my local hard drive through an FTP client. Through an SSH session, I dumped the contents of the database to a .sql file and transferred this file to my local computer, again through FTP. I am now far less paranoid making changes, because I know that I have this backup to fallback on should I mess anything up beyond repair. This backup contains the entire base site, with all design completed per original specifications.
After meeting to discuss the next steps, I will undoubtedly be making more changes to the site. Rather than having to initiate these backups manually each time using the process I described above, I would like to have some way of automatically backing up changes on some sort of a regular schedule. After researching plugins that could accomplish this, I found UpdraftPlus. I wanted to use a plugin rather than something server-side because we will be migrating the WordPress installation to a different server following development. By using a plugin rather than some sort of cron job or script on the server I would eliminate the need to completely reconfigure the backup service after the migration.
After initial setup, I ran a forced backup using the UpdraftPlus plugin. Despite a few files that the tool was unable to backup due to incorrect file permissions, the backup ran smoothly and stored all of the pertinent website data, including a database backup, on my Google Drive account. The only thing that has to be done at this point is to transfer the backup location to someone who will be able to access them if needed following development. I’m very happy to have found a solution to the problem of backing up, and looking forward to not worrying about breaking the website.
I’m typically not much of a long-term planner. While I have defined some goals and aspirations, they sometimes seem more like rambling dreams than achievable objectives. Although I may know what I want, defining actionable items for getting there is a different and far more challenging accomplishment. I like to make the most of every day, doing the best that I can and hoping that hard work and positivity will take me somewhere amazing, wherever that may be.
Much like the story told by Desi in the Draw Your Own Map pattern in Hoover and Oshineye’s Apprenticeship Patterns, I have begun my Information Technology career in a sort of hybrid role in Systems/Application Administration. The differences between my experiences so far, thankfully, have been far different from those described by Desi. Rather than facing pressure to concentrate only on furthering the interests of others, I am encouraged to create a valuable experience for myself.
While I am well aware that it is not the responsibility of anyone else, employer, professor, or colleague, to give me a hand out, I am extremely grateful for all of the support that I have received in that regard. I feel as though I have a good sense of my career position and potential options for the future because of the support that I’ve received and the experiences that I’ve had.
Although I see absolutely no need to consider other paths at this time, the Draw Your Own Map and the stories shared by Desi and Chris were somewhat reassuring. It is comforting to know that even if there comes a time when it may feel like it, you are never really stuck. I feel extremely grateful to currently be in a position where my goals and desires for professional advancement are not only heard and considered, but seem to be top priorities. I am in a supportive, flexible environment, where I’m encouraged to set and work to achieve goals for personal and professional growth, development, and learning. Right now, the possibilities and prospects seem to be wide open. The next step for me is to use this opportunity to discover the values that are important to me.
I completely agree with Kyle McMeekin when he states in a blog post titled “5 Manual Test Case Writing Hacks,” from April 11th, 2016, that it should come as no surprise that great software testers should have an eye for detail. What may not be as obvious, however, is that great software testers should be able to write great and effective test cases. McMeekin goes on to observe that writing effective test cases requires both talent and experience. In an attempt to begin my journey to become a great software tester, I decided that I should pay close attention to the advice offered by experienced testers as they reflect on the skills they have gained from their time in the industry. Hopefully, by following the tips of more experienced testers, I too will someday be able to contribute to highly valuable test cases the improve productivity and help to create high quality software.
The first step to writing great test cases is knowing what components make up the test case. While many of the components were obvious to me, there were others that I had not thought of. The test steps, for example, are important because the person performing the test may not be the same person who wrote the test. Knowing how the test should be performed is important to obtaining a valuable result from the test.
What I found most valuable about McMeekin’s post, however, were his tips on how to “write better test cases that will lead to better quality software for your company.” His first piece of advice is to keep test cases simple. They should be in simple language, and follow the company’s template. Although not specifically mentioned in this guide, I remember reading that if a test case seems to become too complex, you should begin considering breaking it up into smaller pieces. Second, McMeekin recommends making test cases reusable. Taking into consideration that your test cases could be adapted to other scenarios or reused in another application should help to develop test cases that are reusable. Third, McMeekin suggests placing yourself in the shoes of the tester or developer rather than the test-case writer, and being your own critic. Considering what parts of your test-case may be ambiguous or frustrating for others using them will often help to create better tests. This goes hand in hand with the fourth recommendation, which is to think about the end user. Understanding the expectations and desires of the end user will certainly help to create test cases that lead to better, more successful software. The last recommendation that McMeekin gives is to stay organized. This suggestion could apply just about anywhere, but with hundreds or possibly even thousands of potential test cases, staying organized is certainly essential to being a great tester.
Although I am sure there is a great deal more to consider in my quest to one day become a great software tester, I think that keeping these things in mind will certainly improve the quality of the test cases that I write. In the rapidly advancing field of computer science, I don’t feel that I will ever stop learning new and improved ways of doing things or further developing my skills.
While researching how to make the dreams of developing a countdown clock Angular application for the final project of Software Construction, Design, and Architecture, I came across an interesting writeup on the Angular Material Datepicker by one of the Angular Material developers, Miles Malerba. With plans of creating a user-inputted countdown timer, a datepicker component sounded like welcome alternative to making one from scratch. I decided to look further into the Material Datepicker to see if it would be something that could prove useful.
The Material Datepicker includes support for the required attribute, which is used for data validation when a form is submitted. This seems like a worthwhile feature, as it would make little sense to allow the user to create a countdown timer without inputting a date to countdown to. The datepicker also has an additional mdDatepickerFilter attribute, which allows for “finer grained control of what’s considered a valid date.” This also seems like an important feature for a countdown timer input, as I would want to disallow users from selected a date in the past, as this would be invalid to count down to.
While I had not previously thought about supporting mobile users with my countdown timer application, the Material Datepicker’s mention of a specific “touch UI mode” made me reconsider. I think that a countdown timer that is tailored mobile users would be an important audience to appeal to. Perhaps mobile users would have more use for a countdown timer on their phones than on the computer. I will have to look into the possibility of supporting mobile users.
In conclusion, I think that Angular Material Datepicker will certainly help in the development of my Angular Countdown Timer Single Page Application (SPA). Having a datepicker component that is already written will allow me to focus on the more important aspects of design, such as allowing users to save their countdown timers by implementing database calls. While there is certainly still much work to be done on my Angular SPA, reading about the Angular Material Datepicker has me excited to get started developing.