cs260 final portfolio - james arlow

James ArlowCS 260: Technical Writing for Computer Science

Due: May 3, 2016

CS 260: Technical Writing for Computer Science – Final Portfolio – Arlow 1

Table of Contents

3 Prefatory Writer’s Note

4 WA1 – Cover Letter & Resume

7 WA4 – Business Letter

9 WA4 – Instructions

11 WA5 – Specifications Document

15 WA2 – Persuasive Memo

17 WA3 – Issue Report

22 WA6 – Group Project - Proposal

25 WA6 – Group Project - Manual


Prefatory Writer’s Note

Coming from a technical background, my early years as an IT Administrator tended to involve the most technically accurate descriptions possible, while also repeating information at each location it might be relevant. This communication style helped guide wandering minds when speaking directly, but as a writing style, it tended to lose the interest of the audience quickly, and the purpose of my dedication to accuracy ultimately suffered.

Based on these experiences, and in congruence with the principles we covered in class, I've come to value the separation of discrete ideas, the targeted application of abstraction, and the effective use of visual layout in written documents.

As a perfectionist, these refined qualities can impeded the process of getting relevant information from the mind to the page. Previously, I had focused on refining the message before it hits the page, and worked to improve coherency by targeting the language and organization to a specific audience from beginning to end.

I discovered, instead, that putting down all of the information in the order it arrives to me mentally and then sorting and removing redundancies, maximizes the rate of output, leading to an earlier usable draft and a faster process of overall refinement.

The biggest pitfall in this approach is the tendency to overlook stylistic inconsistencies, typos, and grammatical errors that come from reordering the document.

To address this issue, as the draft approaches completion, I read it aloud from the beginning, repeatedly, in order to maximize my potential for identifying errors. Peer review also helps to spot mistakes my familiarity with the history of the document makes it hard for me to see.

Ultimately, working on the document in multiple session has proven to be the best remedy for writer's eye. This is not always an option, but when possible, it encourages me to start writing earlier, so that I have time to repeatedly recenter on the revision process.


WA1 – Cover Letter & Resume

WRITER'S NOTE

The original version of this assignment involved applying for a position as the member of the technical writing class. The framing was kind of awkward, so I avoided getting too specific, and focused insteadon generally applicable qualities to any position.

For the revision, the goals changed to represent a realistic application to a job in my desired field. I targeted a position for Java EE developer at UPS that was recently forwarded to me by a professor. To emphasize my specific interest in the position, and relevant experience, I expanded on my related personal history and skills.

A single page resume was also required. I included a passable resume that I had used in the past. The formatting was slightly diminished during the transfer to this document, but overall, I was happy with the use of formatting to aggregate the wide range of technical skills. I considered removing the subtle humor and unrelated work experience, but felt that it emphasized my hard labor work ethic and personable style.

For further revision, I would focus more on the accompanying portfolio links and updating the emphasis on skills to reflect more recent experience with server application frameworks and deployment technology.


James Arlow

1717 E Main StWaynesboro, VA [email protected]

2016-05-21UPS FreightHuman ResourcesP.O.Box 1216 Richmond, VA 23218-1216

ATTN: Recruiters

Your receipt of this package formalizes our intersecting interest in the fulfillment of your posting. Having reviewed your expectations for the position, I consider myself appropriately qualified.

During my 7 year experience as an IT administrator in a retail environment, I developed practical communication skills in a wide range of context specific roles: data researcher, primary support provider, proprietary hardware specialist, and inter-departmental, inter-organizational liaison. Adaptingto these roles developed my ability to interact with diverse audiences, but it also instilled in me the importance of initiative and iteration in communicating productively and effectively.

During this time, I also focused heavily on independent development of software solutions to supplement the substandard products I inherited. As the sole technical employee, deployment and infrastructure proved more costly than development time, and I developed a keen interest in applicationservers and other enterprise deployment technologies to help manage the balance of concerns.

Having a preference for the Java ecosystem, my later work emphasized a transition to Java EE, and your specific request for related experience attracted my attention. I would enjoy an opportunity to develop this interest in a professional environment, one that can foster my technical aptitude with a strong infrastructure and team environment.

Your company's history providing critical and competent nationwide infrastructure is encouraging. Combined with my current academic focus on formal software development practices, my strong technical base-line, and my history of professional IT experience, I believe this position could be a great place to focus on my passion and career goals.

I look forward to discussing the opportunity with you further.

Sincerely,

James Arlow


Applicant

name James Arlow telephone 540.820.3239 email [email protected] locale Waynesboro, VA

linkedin www.linkedin.com/in/jamesarlowgithub github.com/JollyWizardbitbucket bitbucket.org/jollywizard /

Education

James Madison University Fall 2015+ Computer ScienceCoursera 2014-2015 8 Certified Courses (Scala, R, and Data Science)Blue Ridge Community College 2004-2014 AA&S College Transfer

AS Computer Science Specialization Spotswood High School 1999-2002 Advanced Diploma (Highly Prestigious)

Work History

Freelance IT 2014-2015 Jolly Wizard Computing (Sole Proprietorship)

Skills: Git • Website design and modifications • HTML5 / CSS3+ • jQuery • RequireJS • Markdown • Hosting, email, and network administration • Interfacing with proprietary software vendors • System cleanup • Backup / Recovery • Software / Operating System deployment.

IT Administrator 2007-2014 Rebecca’s Natural Food (Charlottesville, VA)

Skills: Batch scripting • Java app development (process launchers, file processors, web applications) • Proprietary database investigation and scripting (Sybase SQL) • Deployment, administration, and maintenance of physical and virtual machines and related accessories • Grub4Dos (bootloader) scripting • Development and deployment of VBA macros • Wordpress administration and theme modifications • Hosting, email, and network administration • Proprietary RS232 cabling and COM based peripheral management • Network wiring • Management of user expectations • Explanation of user interface idiosyncrasies to non-technical users • Interfacing with third party providers of support and supplies • Secretarial mastery of the number pad for data entry.

Arcade Technician 2005-2006 Diamond Jim’s Arcade (Massanutten, VA)

Skills: Investigate proprietary electrical systems and custom hardware / software interfaces for administration, integration, and maintenance purposes.

Misc Wage Positions 2002-2015 Hank’s Smokehouse, Coca-Cola (Bulk Division), Walmart, Flooring Warehouse USA, O’Charleys, FM Dodson Woodworking

Skills: Operate two different styles of forklifts • Throw and catch 12-packs of soda like a football • Remain productive while wet and greasy • Vigorous sanding • The generous application of oils and waxes.


WA4 – Business Letter

WRITER'S NOTE

The original version of this assignment was a new hire welcome letter that included procedural instructions. For the revision, we were asked to split it up into an employee review and a separate instructional document.

Originally, I chose to compose the business letter in a satirical style, in order to emphasize the difference between proper communication and ethical respect. I contrasted a decidedly cheery and semi-personal tone with placeholder nouns that emphasized the jaded perspective often present in informal workplace critiques.

Expanding on the dichotomy in original the format, I structured the employee review around the idea that many workers are technically competent, productive, and personable, but organizations need to weigh these qualities against the contention that can be generated when other coworkers are contentious about non-professional issues. In order to avoid taking sides, I specifically chose a tone and structure that avoids assigning blame, while emphasizing policy as a mechanism to defuse tensions.I wrapped this in encouraging language that respects the contribution to the company.


Dehumanizing Employees Inc.1 Soul Crushing PlaceModernized, VA 56789

March 20, 2016

Wage Slave10 Binary CircleNaive, VA 67890

Mr Wage Slave:

Congratulations on your 90-day anniversary at Dehumanizing Employees. As part of our new hire policy, we have processed your early evaluation and are happy to inform you that feedback on your performance has been overwhelmingly positive.

Your team supervisors and the Department of Excessive Oversight both report that the quality of your work has remained consistent and technically competent. Productivity metrics also indicate that you acclimated to your designated tasks quickly, and your attendance rate is among the best in the company.We appreciate the skill and dedication you have brought to the position so far.

We have received a few complaints that your music listening habits have disturbed some of your coworkers. While we begrudgingly accept freedom of choice regarding artistic expression, it is important to maintain an equilibrium of cohesion in the workplace. Company policy is to require headphones when a consensus on ambient music cannot be reached. Please note that wearing headphones does not excuse you from the responsibilities of workplace communication.

We look forward to your continued presence on the team, and expect similar positive results during your one year review.

Sincerely,

James ArlowInterim OverlordDehumanizing Employees Incorporated


WA4 – Instructions

WRITER'S NOTE

The original version of this assignment was a new hire welcome letter that included procedural instructions. For the revision, we were asked to split it up into an employee review and a separate instructional document.

For the instruction portion, I imagined a system where new hires at a technical company could simultaneously demonstrate *nix terminal skills while completing their on-boarding process. This proved to be fairly coherent, and translated to a readable instruction set that in-lined well with the language of the original letter.

For the revision, as the instructions were already coherent, I refractored the original nested list layout, into an overview list, with header sections that lead to instructions for each list item. This allowed for easier readability of important information and related descriptions. Language was adjusted to remove the implication that it was part of a larger, colloquial document.


Onboarding Process Instructions

OverviewThe onboarding process must be completed using the dedicated terminal server.

The following steps must be completed in order:1. Use SSH to log onto the server.2. Review the required documents.3. Use the interactive script to verify your review.4. Configure your HR account credentials.5. Finalize the process by logging into your HR account.

1. Use SSH to log onto the server.

URL onboarding.dehumanizing.comUser Your zip code followed by the last four digits of your SSN.Password The contact phone number provided on your application (i.e. 5551234567).

2. Review the required documents.

offering/details.txt Position requirements, salary, and associated benefits.offering/liability.txt Legal disclaimers and liability policies.offering/handbook.pdf Complete reference of company policies and guidelines.

3. Use the interactive script to verify your review.

Script offering/accept.sh

When prompted:• Confirm that you have reviewed and accept the material.• Correctly answer the 5 randomized questions about the material.

When complete:• Write down your confirmation code. You will need this in step 5.

4. Configure your HR account credentials.

Script offering/credentials.sh

When prompted:• Enter a username and password.

5. Finalize the process by logging into your HR account

URL hr.dehumanizing.com.

• The URL should be accessed in a HTML5 compliant browser.• Follow the on-screen prompts to provide your information.• When asked for your confirmation code, use the code provided by `accept.sh`.


WA5 – Specifications Document

WRITER'S NOTE

For this assignment, we were asked to write a portion of a specification document using the format of the Volere template. I chose to write Section 1 (i.e. Background and Project Goals). The project proposal was one that I had considered, based on my ongoing experiences in the merchandising live plant goods.

While I had extensive experience with merchandising arrangements and retail data systems, this business sector posed some unique challenges, and I found that comparative strength of my company's software systems was undercut by the increased complexity of the business concerns. As a software development enthusiast, I wanted to believe that I could describe and solve those shortcomings, and this was a chance to test that in a structured proposal process.

I found the template document itself confusing, and my peer review draft included a section for each section's criteria and consideration items. After realizing the irony, that a technical writing template should suffer from confusing use of page layout to convey context, I removed the resulting redundancy and the result was considerably more coherent.

Peer review and submission draft critique also indicated that I was not effectively conveying measurable goals. I found this a bit odd, because the final paragraphs explicitly emphasized the terms 'metric' and 'measurement', as well as user perspective language I considered specific enough to survey.

For this revision, I replaced the plain language format of the original with lists and headers, in order to better convey the goals of each subsection. This helped to improve the clarity in addressing feedback, and improved the tone of the document to make it more formal.


Water GuardianA Software System Proposal For Live Plant Merchandisers

1a. The User Business or Background of the Project Effort

Merchandising live plants in a retail environment requires ongoing care to ensure the liveliness and quality

of product. Competency in care techniques and awareness of product state must exist among the staff,

leadership, and vendor representatives in order to ensure profitability.

To effectively manage these concerns and protect their mutual investment, vendors and retailers must

establish coherent delineation of responsibilities and liability.

One technique to address this is colloquially known as `Pay by Scan`. Under such a system:

• Payments are withheld till the time of sale.

◦ Retailers are paid by the customer at the time of sale.

◦ Retailers pay the vendor for the product at the time of sale.

• Responsibilities are split between parties.

◦ Retailers are responsible for ongoing care.

◦ Vendors are responsible for verifying the quality of care.

• Liability is split between concerns.

◦ Retailers are liable for the costs of product care and customer service.

◦ Vendors are liable for the costs of production, distribution, and shrinkage.

Concerns in Pay by Scan Arrangements

Theoretically, each stakeholder group is expected to be actively involved in the quality of care:

• Retail staff handles the execution of product care.

• Retail leadership ensures staff availability for care, and supervises the quality of execution.

• Vendors act as a safeguard, by communicating quality issues to retail staff and leadership.

If any stakeholder group fails to maintain their role, there is a potential liability in product loss and reduced

opportunities for profitability.


Managing Concerns in Pay by Scan Arrangements

When managed without specialized tools or systems:

• The quality of care is dependent on the initiative and competency of each stakeholder group.

• Retail leadership and vendors must synchronize their review and communication of care quality.

• Quantitative data is not generated, limiting the metrics available for review and planning.

When managed with with specialized tools or systems:

• Quantitative data can be made available to analyze trends and improve planning procedures.

• Communication and review can occur asynchronously.

• Initiative and competency can be tracked and compensated for.

Specialized tools and systems can have their own shortcomings:

• The effort required to record and review data can deter participation.

• Related data can be split between multiple systems, limiting usability.

• The resolution of data can be low, limiting utility.

• Relevant parties may not have access.

Solution

In order to decentralize responsibility and increase the availability and detail of usable metrics, a system

must exist that allows all parties to track, share, and review relevant care and quality information with

mechanisms conducive to retail and distribution environments.

1b. Goals of the Project

The deliverable goal of the project is a visual software interface that allows retail staff, leadership, and

vendors to coordinate, verify, and track the care and quality of live plant products.

By improving the ability of the all stakeholders to share and access information related to care and quality,

the project hopes to drive the involvement and effectiveness of all parties in controlling inventory loss and

driving profitability.


Measuring Project Goals

Usability and Informative Ability

The product should be usable and informative enough to drive user involvement in care procedures.

To verify usability and information availability, user perception can be measured with surveys:

◦ Stakeholders should feel comfortable using the product.

◦ Stakeholders should feel able to easily access and enter care and quality information.

◦ Stakeholders should feel the system can provide information that can be visually verified.

◦ Stakeholders should feel the system provides information beyond what is visually available.

◦ Stakeholders should feel the product can be a substitute for verbal and written communication.

◦ Retail leadership should feel the product provides the information they need for planning.

◦ Retail staff should feel the product can be used as a substitute for direct leadership.

◦ Vendors should feel able to verify the level of involvement of all parties in product care.

Inventory Control

The product should improve the ability of all parties to limit the negative effects of shrinkage.

To ensure the product is effective at improving the shrinkage metric:

• Inventory measurements should be taken before and after implementation to verify improvement.

• Changes in distribution patterns should be considered to normalize projected expectations.

Correlating Goals

To ensure that product usability is related to shrinkage improvement:

• Shrinkage can be compared to usage logs to correlate user involvement to change.


WA2 – Persuasive Memo

WRITER'S NOTE

For this assignment, we were asked to compose a persuasive memo to address an organizational issue. I chose to focus on the lack of control JMU students are given over the receipt of bulk emails.

Criticism of my original submission included a lack of clear suggestion in the introduction, and a overly confrontational attitude towards the issue. Being rooted in personal frustration, there was a lot of `tsk-tsk` finger waggling towards the university for skirting the ethical concerns involved.

For the revision, I focused on condensing the document's organization for clarity, applying more emphasize on the positive results of change, and treating the university as an innocent party in need of direction.


Fellow students and faculty:

As many of you may have noticed, students at the university are automatically enrolled in multiple tiersof bulk mailing lists. Personally, I've experienced productivity and communication issues related to thelarge quantity of emails coming out of these programs. While I understand that the university brings together a diverse body of student interest groups and administrative concerns, I suspect the lack of controls available to manage these communications is also hurting the ability of other students to effectively use their student email.

I believe these issues can be solved by implementing granular controls for university mailing lists. I think that doing so would increase the ability of students to effectively use the system, and also bring the university's technical policies in line with the ethical guidelines we expect in the consumer space.

Regarding the need for increased productivity, in my own case, the volume of emails originating from these “approved university mailings” composed the obvious majority of the 600+ emails I received last semester. Not only did they outpace official communications from my instructors, university administrative systems, and classmates, they outnumbered all interpersonal communications combined with periodic and promotional emails from third party services registered to the address.

The impact of this deluge was not trivial. On multiple occasions I failed to identify important emails nested within sequences of bulk mailings. Deadlines were missed, and communications were found after the conversations they were supposed to prepare me for. Because the frequency of irrelevant emails outpaced both my personal and professional accounts, I disabled the smartphone notifications which had proven to offer more nuisance that utility. In turn, I was even less aware of the arrival of important communications.

In an effort to get back in the game, I tried to unsubscribe from as many of mailers as possible, but quickly discovered this option was not available for emails that originate from the majority of university lists. As a modern Internet user, I was keenly aware of the level of concern, legally and ethically, that unsolicited emails can generate. I found it concerning that these important social issues could be overlooked across the university.

For my own part, as a father who works full time to provide food and shelter for his family, I have zero need for student housing promotions, meal plans, or student work and study abroad programs. As a matter of personal preference, time constraints, and philosophy, I also have zero interest in university sports, Greek life, or life planning and study skill seminars. As part of my enrollment, many of these demographic indicators had already been submitted to the university in one form or another, and it occurred to me that it would be more respectful, and less redundant, if that information had been applied to mailing list policy in the first place.

Of course, I also understand that many students will find relevance in bulk mailers, even in contrast to their demographic indicators. University mailers have their place, and reform targeting the lack of demographic relevance should focus on providing granular controls and opt-out mechanisms that mirror the facilities already provided and legally mandated in the consumer and business sectors.

With some simple account controls, I believe we can empower students to get the most out of their university email accounts, and improve the ethical framework involved in the process.


WA3 – Issue Report

WRITER'S NOTE

For this document, we applied our study of formal reports in organizations to a real workplace issue.

I was studying Docker at the time, based on its prevalence in the news cycle. I understood that the technology was new and valuable, but that the hype driving it's adoption had also come under question.

Being enthusiastic about my research and its contemporary relevance, I was keen to engage willing listeners, but the scope and complexity of the issues tended to ward off audiences and distract from potential benefits. I was also repeating long diatribes to small audiences.

We covered informative abstracts leading up this assignment, and it seemed an appropriate format for the requirements and topic. The Docker topic was broad, divisive, and popular enough to generate a detailed and balanced report. I also knew, from my research, that many organizations had to be analyzing the topic internally through similar means. On a personal level, it was also a chance for me take my water cooler ramblings and turn them into something tangible and reusable.

The original draft was based largely on my own ad-hoc research and experimentation, and was focused more on the technology background, benefits, and shortcomings I had experienced. I quickly reached the upper limit of the assignment length, and had to settle on the topics I felt were most likely to confuse newcomers.

Following our peer review session, I looked for third party sources to verify as much of my own findings as possible. In the process, I learned that my concerns as a personal developer were a small facet of the complexity driving Docker's direction, proponents, and critics. In order to expand the report to cover the range of new perspectives I encountered, the majority of my original report had to be completely replaced.

Sourced materials, from qualified parties, was used to emphasize the diversity of industry perspective. When summarizing the technology and the sources of its media prevalence, I continued to rely on my own perspective, as the topics were fundamental and wouldn't benefit from third party references.

Critical feedback on my final draft centered on the unclear goals of the report, which ironically resonated with the deeper issues surrounding Docker adoption and its future. I tried to clarify these issues for the final portfolio. While I'm not sure if I met the criteria for clarity to a general audience, I think it's appropriate for the intended primary audience, technical teams empowered to make infrastructure decisions.


Industry Perspectives on DockerQ1 2016

SynopsisDocker (and its family of complementary applications) is an emerging open source software platform centering on the distributed deployment of applications and servers. Establishing itself as the de facto standard in the emerging deployment paradigm known as Linux containers, Docker has received ample,media coverage with emphasis on rapid adoption rates (Datadog Docker Adoption), impressive venturecapital figures (Fortune - Docker Funding), and high profile industry endorsements (Docker Company). Conversely, critics and proponents have pointed to shifting organizational goals behind the project and areas where the platform is still underdeveloped.

Teams and organizations interested in adopting Docker are presented with a diverse and evolving landscape of information and perspectives to consider. This report aims to summarize the platform from a technical and industry perspective, circa Q1 2016, in order to provide background for further research and to help bring teams and stakeholders up to speed on the benefits, history, future, and conflicting perspectives regarding Docker as a product, a tool, an ecosystem, and a company.

Docker OverviewThe first public release of Docker was in March 2013, when it transitioned from a private project at PaaS specialist CloudNet to an open source project under the direction of a dedicated support and development company, Docker Inc. (Docker Company).

At a technical level, Docker is derived from modern improvements to the Linux kernel often referred toas containers. Linux containers use system security features to isolate software so it appears to be running on separate, dedicated systems. In contrast to virtual machines, which achieve similar goals by emulating entire systems, containers reuse the essential system functions provided by the kernel of the host OS, rather than spend resources on emulation.

The potential to leverage container technology to disrupt and simplify the ubiquitous VM workflows inenterprise computing environments has been a driving factor in the media interest behind Docker. Its impressive market velocity can be contributed, in large part, to its first-to-market role in the field. By establishing itself as the predominant standard and driving force behind the technology, Docker has secured major industry and community alliances, capturing the watchful eye of the media in process.

The namesake product itself consists of the Docker engine and the Docker client, which together provide the ability to create and control containers. The engine runs as a system daemon, and provides the system level facilities to build, control, monitor, network, and share container deployments. The client provides command line integration for the engine and remote connections to running containers.


Docker Extended FamilyDocker Inc. provides an array of complementary products that aim to simplify the use of the core Docker features in complicated scenarios.

• Docker Machine, for provisioning remote hosts and exposing control to the client.

• Docker Swarm, for controlling a cluster of hosts as a single virtual host.

• Docker Compose, for building and deploying applications that require multiple containers.

• Docker Toolbox, bundles other tools and configures non-Linux hosts using Docker.

Industry AdoptionInterest in the future impact of Linux containers and Docker’s emerging role as a forerunner in the fieldhas led to high profile adoptions and integration commitments from major vendors (Docker Company) (Docker Customers).

• In September 2013, Docker and Red Hat announced a major alliance, including Fedora/RHEL compatibility, and Docker as a container standard in OpenShift.

• In October 2014, Docker and Microsoft Partner to drive adoption of distributed applications, with a commitment of support in future editions of Windows Server.

• Official customers include veteran and upcoming industry leaders including: Spotify, Ebay, Paypal, Uber, Shopify, Groupon, Lyft, Baidu, Yelp, BBC News, and The New York Times.

Because of its infancy, detailed statistics on industry adoption are scarce in comparison to speculative media and blogging analysis, however, rapid adoption, particularly in 2015, has provided industry penetration reflected in encouraging statistical studies.

Cloud monitoring specialists Datadog reported in August 2015 that out of thousands of clients, Docker market share went from less than 2% to greater than 8% of all customers and less than 1% to greater than 6% of monitored systems (Datadog Docker Adoption). Datadog also found that the large companies were the most likely to be early adopters and that the majority of companies that adopted Docker experimentally continued to use it, with most escalating their usage rapidly after the initial adoption period.

In October 2015, a commissioned survey of O’Reilly Media’s user community also presented encouraging figures on Docker adoption (Container Journal – Container Ecosystems).

• More than 93 percent of respondents are already using or plan to use containers for development, testing, or production.

• The vast majority (78 percent) are opting for Docker.

• Fast and easy deployment is the most important reason for using Docker (85 percent).


Critical PerspectivesDespite the rapid adoption and high retention levels in the industry, commentary has raised concerns about technical issues with the platform that complicate essential use cases.

• In July 2015, Simon Eskildsen, of featured partner Spotify, blogged about an assortment of technicalities that limit Docker's applicability in production scenarios (Eskildsen).

• Similarly, in March 2013, HeavyBit, and coalition of developers focused on fostering startup developers, posted a retrospective on their developer conference targeting `Docker in Production` which noted key issues currently affecting the Docker ecosystem, particularly in relation to distributed storage and tooling for orchestration (HeavyBit).

Other critics have taken issues with the goals and usability of the Docker platform itself.

• In December 2014, CoreOS, a leading cloud ready Linux distribution, announced a compatible competing platform `rkt` in response to their perception that Docker had turned away from its commitment to developing container technology and interoperability in favor of specialty products aimed at the distributed computing market (CoreOS Rocket Introduction). CoreOS noted that all `rkt` functionality existed in the client in order to address criticisms of the engine-client design implemented by Docker.

• DevOps consultant and author Matt Jaynes posted about common misconceptions about Dockerabilities and practices that can be problematic and introduce complexities (Jaynes).

• As of January 2016, guerilla website boycottdocker.org hosts concerns about Docker, in terms of its abilities in comparison to virtual machines, its lack of security standards, and a tendency to foster vendor lock in within the Docker platform and ecosystem (boycottdocker.org).

• In January 2015, blogger and specialist Cal Lemming posted a critique of various hassles in dealing with Docker’s limitations, while reminding readers that the core capabilities behind the technology are already available to through low-level facilities (Lemming).

SummaryDocker adoption has undergone impressive growth in its three year public lifespan. Combined with enthusiasm for the emerging technology standards behind it, industry leaders have been quick to adopt and integrate with the platform, and retention among clients has been noticeably consistent.

Despite the encouraging velocity of the platform, teams looking to adopt Docker technologies still needto consider the core platform’s abilities regarding their desired use cases and stay aware of the evolvingecosystem of related first and third party products. Research suggests that most teams will find success with the platform and that it is conducive to a transitional approach.


ReferencesContainer Journal - Container Ecosystems. n.d.

<http://containerjournal.com/category/topics/container-ecosystems/>.

CoreOS Rocket Introduction. n.d. <http://coreos.com/blog/rocket/>.

DataDog Docker Adoption. n.d. <https://www.datadoghq.com/docker-adoption/>.

Docker Customers. n.d. <https://www.docker.com/customers>.

Docker Company. n.d. <http://www.docker.com/company>.

Docker Compose. n.d. <https://github.com/docker/compose>.

Docker Machine. n.d. <https://github.com/docker/machine>.

Docker Swarm. n.d. <http://github.com/docker/swarm>.

Docker Toolbox. n.d. <https://github.com/docker/toolbox>.

Fortune - Docker Funding. n.d. <http://fortune.com/2015/04/16/docker-funding-container/>.

Jaynes, Docker Misconceptions. n.d. <https://valdhaus.co/writings/docker-misconceptions/>

BoycottDocker.org. n.d. <http://boycottdocker.org>

Lemming, Docker Hype. n.d. <http://iops.io/blog/docker-hype>

HeavyBit, Docker in Production. n.d. <http://blog.heavybit.com/blog/2015/3/23/dockermeetup>

Eskildson, Why Docker is Not Yet Succeeding Widely in Production. n.d. <http://sirupsen.com/production-docker>


WA6 – Group Project - Proposal

WRITER'S NOTE

Our final assignment was a group project. We were asked to collectively prepare a project proposal, along with a post implementation manual, and a promotional social media package.

The proposal chosen was the integration of features from JMU's unified service backend, MyMadison, into the LMS, Canvas.

I ended up being responsible for the social media package, and I had to work remotely, so the proposal and manual were done without consulting me. The results deviated significantly from our initial planning sessions, and I personally felt the quality of the writing ended up being very poor from a technical standpoint, and the results lacked professional rigor. Unfortunately, the rest of the group chose to put all of their work off until the last moment, so by the time I finally had access, it was too late to contribute meaningful improvements.

For the revision, I focused on bringing their effort in line with my personal standards.

In terms of the writing style, there was a lot of suggestive dependent clauses that fluffed out the underlying ideas with rhetorical sentiment, but hindered the readability, organization, and professional quality of the document. I deleted all of the rambling rhetoric and replaced it with bullets and leads that conveyed the same logical points without the emotionally charged and unproven deviations.

Regarding the content, the rest of the group chose to frame the deliverables around imaginary research results and collected data. The results were used to validate subjective opinions and lacked technical accuracy, while eschewing legitimate facts that could have been used to back up the ideas instead. For the revision, I focused on excising all of this nonsense.

The plan of action portion was composed entirely of such fairy dust, combined with more rhetorical fluff. I really couldn't find a way to fix it, so I rewrote the section as a general proposal to integrate legacy back-end services into modern content management systems. The result was significantly more coherent and technically accurate.

Structurally, the team's outline of the document was actually passable, but I felt the use of a conclusion was perfunctory after the imaginary data and rhetoric were stripped away. Since the cleaned up versionwas only two pages anyway, and the first page effectively conveyed any points that would have been made in an essay style conclusion, I just removed it entirely.


Introduction

Statement of Problem

Students at JMU must work with two separate but related data systems:

• MyMadison : A human resources application that coordinates account services.• Canvas : A Learning Management System that coordinates education materials.

MyMadison is difficult to use in comparison:

• The same password is used on both systems.• MyMadison requires extra layers of security.

• MyMadison joins multiple data systems, but each system is separate and nested.• Canvas joins multiple services, but each is logically integrated with Canvas features.

• Each MyMadison system has its own, often dated look and feel.• Canvas is designed with a unified, modern look and feel.

• MyMadison services are often legacy system, causing issues with browser features such as the back buttons, multiple tabs, and password management.

• Canvas is open source and built to modern web design standards.

Objective

Because Canvas supports the integration of services as top level features, we propose integrating the most used student services from MyMadison.

Specifically, we would like Canvas to support:

1. Class Enrollment2. Class Schedules3. Transcripts and Academic Requirements

Benefits

Moving key academic services into Canvas will improve usability of essential services:

• Modern browser support will reduce errors related to legacy system incompatibilities.• The modern look and feel will improve user satisfaction and information readability. • The coherent and consistent navigation system will improve usability.• Simplified navigation will translate to improved server load and responsiveness.• Simplified security policies will improve student access to services.


Proposed Plan

Each proposed integration can be split into distinct concerns:

• Isolation of services that do not require access to MyMadison to integrate.• Preparation of development resources to integrate with Canvas.• Authorization of integration code to access service data.• Translation of service data into a modular micro-service.• Integration of micro-service into the Canvas user interface.

Isolation

Because MyMadison acts as a front-end for other data systems, the first phase is to research which systems can be accessed without going through MyMadison.

Direct access to back-end systems is likely to provide easier access to developer features, and ensures that MyMadison performance is not a bottleneck for feature integration.

Preparation

Before development begins, programming languages and tools must be chosen that will be compatible with the final phases of the project.

Testing trivial feature integrations first will ensure that effort is not wasted using tools or methods that are not actually compatible with the final stages of Canvas development.

Authorization

Once the point of access for each feature is established, and development tools have been readied, the next phase is to authorize code to access the desired information.

Each point of access will have its own requirements, but some may be shared. Compatible systems should be developed first to maximize the availability of work for later phases.

Translation

After the developers have access to the back-end service, the code needs to extract the information specific to the target feature.

Integration

Once the feature's data is available, the final stage will be to convert it and integrate it with thevisual format of the Canvas user interface.


WA6 – Group Project - Manual

WRITER'S NOTE

Our final assignment was a group project. We were asked to collectively prepare a project proposal, along with a post implementation manual, and a promotional social media package.

The proposal chosen was the integration of features from JMU's unified service backend, MyMadison, into the LMS, Canvas.

I ended up being responsible for the social media package, and I had to work remotely, so the proposal and manual were done without consulting me. The results deviated significantly from our initial planning sessions, and I personally felt the quality of the writing ended up being very poor from a technical standpoint, and the results lacked professional rigor. Unfortunately, the rest of the group chose to put all of their work off until the last moment, so by the time I finally had access, it was too late to contribute meaningful improvements.

As with the proposal, the group injected the manual with lots of rhetoric that didn't seem appropriate for the format or professional. On top of that, they violated the golden rule of technical writing, focus on an audience and purpose.

We had proposed to integrate features from one system to another, and they wrote an unfocused and poorly formatted manual for the original system.

Rather than rewrite a 12 page manual that I felt was largely perfunctory, I reused their well done screenshots to create a simple pamphlet that visually instructs students on how to find the old features in the new system.

I ignored the fact that system they described would require complex steps to find the class schedule, as this completely deviated from our discussions during planning.


MyMadison Features in Canvas

The most popular MyMadison features are now available in Canvas.

Enrollment

Class Schedules

Academic Reports
