Week three and mission two are completed. My thanks to Christian Haas for feedback and some additional commentary in this post :).
This week's homework for Blog More is to complete an outline for each of the three blog post ideas.
Homework:
1. Post your favorite outline below.
2. Find someone’s posted outline in the group and give them some feedback. What stands out to you? What points were most interesting? What did you want to learn more about? Be kind but specific in your feedback.
Mission 2: Outlines and Schedules
My Top Three
1. Writing Code around Accessibility and Inclusive Design
- Intro: a quick explanation as to what Accessibility and Inclusive Design are.
- Sample Code that is not accessible and why (web example)
- Using Inclusive Design Patterns to help set the stage
- Changes to code that will make it more accessible
- Methods to check and validate such things
- Sample Code that now IS accessible and why (web example)
My initial thoughts:
I’m realizing this is a topic I could write examples for every week for a year and probably still have plenty to write about. I will probably have to tailor this down to an introductory article first and then go into specifics about individual inclusive design patterns, etc.Christian's comments:
I'm curious about this topic as a whole. For me, your first entry could be about setting the stage, with one or two examples showcasing how far the topic could reach. I myself am more interested from a theoretical point of view. It would affect my daily work only if there were info/references to "closed" systems; I'm not working on web UI, but for a dedicated, trained, target audience using Java UI.
My follow-on thoughts based on feedback:
This is an interesting angle and one I hadn't considered. How do we make applications accessible in a more specific programmatic focus? By Java UI I am assuming these are applications that have a command line style interface or otherwise interactions at the Operating System level and not online or via the web. To be honest, I haven't given a lot of thought to how this would work for a command line application, but it's an interesting thought experiment. When I'm writing a script or some interactive piece of code, how Accessible or Inclusive am I making those interactions? Definitely worth considering.
2. Skeleton Keys: a resource for TDD/BDD in the shell and other programming languages
- What is skeleton-keys?
- Why would anyone need it?
- TDD/BDD in the shell? Really?
- Unit Testing Tools in three languages (bash, ruby, and python)
- Starting small: structure, tests, and output
- Compare and Contrast the three languages and approaches
My initial thoughts:
Why did I pick three languages? OY!!! Oh yeah, so I could actually make some comparisons. I think these might end up being rather long (like book chapter long), but on the plus side, once I get this started, I will probably have plenty to write about for a very long time.
Christina's comments:
Bash: yes - Ruby/Python: is there a particular reason to have both? I don't have experience in either language and see (from the outside) they are somewhat similar in terms of capabilities. Mainly procedural with object-oriented additions; weak type system, and interpreted. For a broader coverage, it should have a variation in perhaps at least two of these points. (e.g., using C, C++, Java, C#, Go, or ...). Since you already identify that this can be done in various languages (taking time and effort to write this), I suggest that, if you want three initial examples, they should be quite distinct from each other. Or reduce to two. (Or give particular reason why Ruby & Python)
My follow-on thoughts:
This is a very good point. I picked Ruby and Python mostly because they are languages I'd been either working with or had some recent exposure to and wanted to set up as a way to focus on some starting poitns for those languages. Having said that, they are two languages that fill a similar niche. They're not the exact same, but Christian makes a good point that they are similar enough that they may not prove to be all that interesting a comparison. Perhaps using a language such as Java or C++ would make more sense, though I haven't used either in a meaningful way in a long time. Still, for this purpose, it may make for a more interesting comparison, so worth re-examining.
3. Creating a framework from the ground up (Jenkins, Docker, Protractor, Angular, Jasmine)
- You Keep using that ‘Framework’ word. I don’t think it means what you think it means.
- Jigging your Jig-Saw Pieces (short intro/tutorial on all five pieces, including installation)
- Setting up a basic application to test
- Puting the onion back together
- writing the Angular App
- testing with Protractor/Jasmine
- putting it into Docker
- managing it with Jenkins
- Lather, rinse, repeat
My initial thoughts:
This would make for a great series with a minimum of five posts for each piece (plus the many that I haven’t even mentioned yet, such as plug-ins or add ons to make the job easier to manage).Christian's comments:
With your first point about using "framework" wrong, I suspect this title is intentional. Still, is the overall goal to write a Javascript based template project?
If so, I'd be less interested as I don't work in JavaScript (That should not be a reason to change your goal, I understand that), though, if it were pitched as "how to create a template stack with Jenkins, Docker, ..." might be half interested as I'd consider an automation pipeline for different languages. Perhaps this could even be a two-parter: How to set up a build-pipeline with Jenkins & Docker and then specializing it for a JavaScript project, and then specializing it for a Java project for instance... (These are all just ideas, I believe your thoughts go already in that direction...)
My follow-on thoughts:
Yes, the use of the word "framework" in both the title and the shout-out to The Princess Bride reference is in part to say that the word framework gets thrown around a lot and maybe doesn't really mean what a lot of people think it means. My goal is to address the broad areas and try to see how to implement the pieces. Just setting up the scenario would be a series of posts (setting up Jenkins, working with git, creating docker containers, setting up a project, making tests for the project, running those tests, making sure they integrate with the CI pipeline, etc.). Perhaps skeleton-keys could be the project that allows me to put this all together and integrate into a series of posts.
One thing is certain, this challenge series is showing me that there are plenty of things to write about in these spaces and I will probably have ample to write about for a long time.
No comments:
Post a Comment