Geeking out about fiddle rosin, Part 1

This is a super-late post, as I’ve been lagging a lot on blogging. But I want to clear out my Drafts folder in WordPress, so here we go!
If you follow me on Facebook, you already saw me geeking out about this, this past late December/early January. But for the rest of you, here’s a post all about how I’ve been able to test various kinds of fiddle rosin I got from Dara as a holiday present.
My fiddle teacher, Lisa Ornstein, had suggested that I get better rosin to improve my sound. Up till that point, I’d been using the rosin I got with the instrument: a block of d’Addario Natural Light.
She recommended Salchow, so I put that on my wishlist–both the Light and the Dark kinds, as I didn’t know which one I wanted. But for 2018’s Solstice/Yule/Christmas/fill-in-your-favorite-winter-holiday-here, my belovedest Dara got me five different kinds of rosin. What she got me included:

Pyramid of Rosin
Pyramid of Rosin

  • Salchow Light
  • Salchow Dark
  • Jade L’Opera
  • Pirastro Goldflex
  • Pirastro Schwarz

This, for the record, is a whole helluva lot of rosin. Lisa was deeply amused when I told her about this, too. Essentially, I have a lifetime’s supply of rosin here. But Dara maintained (and I agree with her) that it was appropriate to get a whole bunch of types to try out, so I could make an informed decision on which ones I liked best.
I did some preliminary tests when I got all of these, throughout the first couple weeks of January. So far I prefer the Jade, with a side helping of the Pirastro Schwarz. The Jade gives my instrument a nice clear bright sound, while the Pirastro Schwarz adds a bit more depth and nuance that I appreciate.
However, I learned that since multiple rosins on a bow at once can have different effects on your sound, I didn’t really properly test the Salchows and the Pirastro Goldflex. With the cloth I’m using to clean my strings, I can take care of this problem. If I very gently stroke it along my bow hairs, this helps eliminate prior rosin residue.
So now, for anybody who might find me when they’re looking up what sort of rosin to get, I’ll do a few more posts about my experiments with this stuff. (Particularly since I want to give the Salchows and the Pirastro Goldflex a better shake.) I’ll talk about all five types of rosin, cleaning the bow before switching to each. And I’ll record a sample of how I sound with each as well, to see if I can detect any differences.
This should be fun. Stand by for more to come!

Coding projects update

As of this writing, I now have a total of five repositories on my Github account: the misc-configs repo for various config/supplementary files, and two each for Java and Python work. For each of those languages, I have a repo for the REST API portion of this project, and one for the Selenium.

All of the repos can be seen on my Github account.

What I’ve been calling the rough “phase 1” of this project is now more or less complete. I’ve got basic test cases in place in both languages for both the REST API side, and the Selenium side. As I’ve written about before, the API tests are dealing with the service endpoints that handle publicly viewable information. The Selenium tests are mostly oriented around testing parts of the homepage of my little test WordPress site.

Now I’m moving into the rough “phase 2”. In this phase, I’m adding more Selenium tests. This’ll include adding some sidebar tests for the homepage, as well as tests for additional sections of the site (a post and a page), and making sure that the elements are correct on the selected links. I’ll also be testing site search and adding a new comment to a previously existing post, since that’s something I can do without authentication.

“Phase 3” of this project will get into dealing with stuff that requires authentication. From the REST API side, this’ll mean dealing with the service endpoints that handle things at the site admin level (such as making a new post or comment, or editing a previously existing one). From the Selenium side, I’ll want to see about verifying logging in and logging out of the site, and making sure that the links displayed in the “META” area of the sidebar update themselves accordingly.

(NOTE: I am NOT going to try to test the actual WordPress admin UI. That’s a whole different kettle of fish than testing a front-facing site.)

In related news, I’ve also discovered the Githubs “Projects” functionality, and I’ve made myself a project there to cover the work I’m doing. This amuses me, as their Projects board looks a lot like JIRA, the bug tracking/project management software we used at my Former Day Job, as well as at the short contract I had after the layoff at the tail end of last year.

Interested parties can find my current active project on my Github projects page. I’ll be adding additional projects to that once this one is complete–like the WordPress plugin work I want to do!

I’ve actually had job recruiters and interviewers ask me about this work, now that I’ve got a link to my Github on my resume. This has proven beneficial in interviews I had last week, and I even got useful tips on additional libraries I can research, as well as aspects of version 8 of Java I hadn’t had experience with yet. I’ve gotten positive feedback about how I do comments on things, as well as on the various Readmes I’ve put on the repos.

So while the work hasn’t yet actually proven critical in landing me a job, it has proven useful in helping me demonstrate that I not only know how to code, but that I like it well enough to do it on my own time and to plan out larger projects.

This is, I feel, a very valuable thing for me to be able to demonstrate.

Coding projects update

I now have three active repositories up on my Github account. These are:

misc-configs: This one is for miscellaneous config files that are useful for the tests in the other repositories. What’s in here will mostly make sense to you if you are familiar with a) how to import data into a WordPress site, b) how to import Collections or Environment files into Postman, and/or c) how to use a YAML file to run Docker Compose to launch one or more containers.

wp-test-demo-java: This one is for my demo of testing the REST API endpoints made available by WordPress for any given site. Phase 1 of the work on this demo is complete, in which I test against the endpoints that handle publicly accessible data. I.e., the kinds of things you could find out about a WordPress site if you’re just a visitor to the site.

wp-test-demo-java-selenium: This demo is also using my test WordPress site, but here, I am doing front end testing rather than service testing. I’m using the Selenide Java library to run tests against the site via Selenium, a widely used automation framework for testing web pages. Selenide is a layer on top of Selenium that does the heavy lifting of Selenium setup for me, and frees me up to focus on the test cases I want to run.

This is a work in progress, but as of this post it has 27 test cases in it. There are more to come.

Other projects that’ll be showing up on my Github account include:

  • Phase 2 of the REST API project, which would involve hitting service endpoints that specifically require authentication.
  • Porting the Selenium tests over into Python, and structuring them in such a way as to be similar to the Python test framework we used on my former team at Big Fish. The intent here would be to demonstrate my ability to use Selenium in Python, and to write up a framework for it. (Which will require more work than the equivalent testing in Java!)
  • The teeny WordPress plugin I want to do that’ll make nice Dreamwidth-style user and community name tags in a post or page for me. (This is the one I’ve mentioned before that would be an expansion on the very old plugin that does this for LJ user and community tags.) This would be written in PHP, and the intent HERE would be to show my comfort level with PHP. I haven’t used this language as much in a professional context, but I HAVE used it a lot over the years dealing with my websites, and I can demonstrate that here.

Stretch goals:

  • Do something in JavaScript. What, I don’t know yet, but the obvious possibility would be to port some or all of the previously mentioned Selenium tests.
  • Since I do have a locally running plugin on annathepiper.org that fuels my Roleplay Logs page, time permitting, I’d like to do a more solid version of that. Right now the plugin I’m running is a hack of the previous non-Wordpress-based code, and it talks to a database outside the WordPress structure. A cleaner version of this would actually be properly integrated with WordPress. If I get really fancy, I could do an entry form in the Admin UI for WordPress to allow the addition of new logs, and possibly even reading them in via the Media section of the site. This would, of course, also be written in PHP. More on this as events warrant!

Today’s WordPress Test Demo update

Good progress on the coding project today! \0/ Things accomplished:

  • Added new test cases involving Categories, Tags, Pages, and Comments, to bring the total number of test cases up to 10
  • Added the ability to run the cases via a Maven configuration as well as TestNG, and updated my pom.xml to use the testng.xml as its suite file
  • Checked all the new test cases and related work into wp-test-demo-java
  • Renamed my wordpress-dev repo to misc-configs, because that’s really what it’s for miscellaneous config files
  • Updated my Postman collection to include all the endpoints for the test cases I wrote today, and checked the new version of that into misc-configs
  • Updated the Readmes on both wp-test-demo-java and misc-configs to more clearly explain what the repos are for, particularly wp-test-demo-java, as I’ll be pointing recruiters at that
  • Installed Jenkins (again) on my dev laptop, so that I can run the automation as a local Jenkins job as well as within IntelliJ, and to keep up my practice using Jenkins

I have decided, too, that I’ll be doing this project in phases.

Phase 1: REST API tests that hit the endpoints that can serve up publicly available data. I.e., the kinds of data you’d see as a user just browsing a WordPress site.

Phase 2: Selenium-based tests that will do front-end type tests. For example, “If I click on this link, does it take me to this expected target page?” Or, “If I click on this thing on the menu, do I get the correct dropdown off of it?”

Phase 3: This is the ambitious part. There are also REST API endpoints for WordPress that’ll let you get at the stuff you’d ONLY see as an authenticated user, such as post revisions and settings and the like. Time permitting, I may learn about the various ways to actually do that authentication properly so that the test suite can actually get at those endpoints.

Right now, though, I’m going to focus on phases 1 and 2.

The WordPress testing demo project is now underway

Spent most of today (very roughly during ‘work’ hours, just to try to keep to the whole idea of coding to a schedule) working on the WordPress testing demo project I talked about in my last post. As of this writing, I have some actual working things checked in up on Github. There’s only one functional test case so far, but it’s a start!

What I accomplished today:

  • Creating a Github repo for this work
  • Read about the API endpoints that WordPress makes available for any given site, some of which are publicly viewable, others of which require you to log in as a valid user
  • Started a Postman Collection to keep track of the endpoints I’ll be playing with for my test site, and checked an initial version of this in on Github
  • Refreshed my memory about how Unirest works, as this was the library we used at Big Fish to talk to various services; maybe not the most current library to use, but it’s the one I know, so I’m going with this for demo purposes
  • Got IntelliJ on the Linux partition of my dev laptop updated to the latest version
  • Built the actual project in IntelliJ, as a Maven project, so it’d have the correct file structure and a pom.xml file I could add dependencies to
  • Started building a client class that will use Unirest to hit those endpoints for my local test site
  • Built a BaseTest class in charge of doing setup used by all the test classes I’ll be making
  • Built a TestPosts class to start the test cases for the “Posts” endpoints in the aforementioned API, and now it even has an initial functional test case!

Now that I have an actual working (if tiny) framework here, I should be able to fill in some test cases reasonably quickly.

Note also that the test suite assumes I am running the WordPress test site locally. For bonus usefulness I should make some sort of healthcheck test case that verifies that the test site is in fact UP.

Further planning for doing my coding demo project

Since I continue to have time on my hands and no active leads bringing me in for interviews this coming week (so far), I’m moving forward with laying down the plans for my coding demo.

As I said in my last post about this (here for those of you reading on Dreamwidth), I’ve succeeded in setting up a test WordPress site in Docker.

The rest of this operation is going to look something like this, at least for phase 1 of this project:

  • Actually get some content into that test WordPress site. This will probably involve just doing a database copy down from my backup WordPress site up on angelahighland.wordpress.com. If for some reason I can’t do that, I’ll install a lorem ipsum generator plugin (there are a few for WordPress, I looked) and generate purely random content.
  • Study up on the REST API WordPress makes available for any given install.
  • Once I know what service endpoints are available, use that to scope out what test cases I can do.
  • Write out those test cases in a Java BVT suite, similar to the ones I wrote at Big Fish. Tools I will need for this: IntelliJ, TestNG.

A possible Phase 2 for this project will involve extending the testing to include front-end testing. In other words (for those of you unfamiliar with how web testing works), hitting the pages of the test site in a browser and verifying that expected things are there, and/or that you are able to do certain things (e.g., log in, do a search, leave a comment). Tools I will need for this: Selenium (also in a Docker image), with a side helping of the Selenide framework. This would be a followup on my previous research that I did as one of my last projects at Big Fish.

Possible stretch goal: replicate some of the same test cases in Python, just to brush up on my Python skills. Tools I’d be using in this part of the work: PyCharm.

I’ve been writing out some tasks for myself in Things, by way of a task breakdown, and I suppose this blog post kind of counts as a spec. Ha. :D

And when I’ve got some actual code, I’ll be checking it in on my personal Github account. This will be fun, hopefully, as well as a way to keep my skills active until such time as I can convince somebody to give me another job!

(EDITING TO ADD: This, by the way, is a separate project I’m planning in addition to doing a WordPress plugin! So I’ll have multiple things I can eventually point at by way of demonstrating I can code. What I’m talking about in this post is more along the lines of demonstrating something similar to the last code I wrote at Big Fish.)

Practicing with running WordPress in Docker today

So one of the things I want to do during my between-jobs downtime is practice my coding. And in particular, since I thought it’d be nice to a) start small and b) play with something I’m actually interested in coding (as opposed to, say, just focusing on random interview-type questions which will eventually bore me to tears), I decided I’d try to play with making a small WordPress plugin.

I’ve already done one that I’m running locally on Annathepiper.org: namely, to show y’all my archive of roleplay logs. Eventually I want to do a newer version of that, something that might let me actually practice setting up a simple web service.

For now though I’m going to do something less complicated. There’s a very old plugin called “lj-tag-parser”. This thing has a very simple job: allowing the LJ-style syntax for usernames and communities in your WordPress posts and comments. I’m using it right here on annathepiper.org, which is why you can actually see LJ-style usernames and tags if I write something like, say, userinfoannathepiper.

However, this thing hasn’t been updated in ages. And I thought it’d be nice to expand it to allow Dreamwidth-style syntax in addition to LJ-style, and possibly also allow generation of such tags via shortcodes.

But before I do all of that, I wanted to make sure I could set up a clean WordPress dev install.

In the past, when I’ve played around with dev-type WordPress stuff, I just did this on a separate blog on my annathepiper.org network. But coming at this with my SDET hat on, I thought it’d be cleaner and more appropriate to developing my coding experience if I set it up the way I’d do it in a work environment.

Which means a brand new, clean WordPress dev install. And in particular, using official WordPress and MySQL images from Docker.

For those of you who aren’t in the tech industry, suffice to say that Docker is a tool that lets you do exactly this kind of thing. You can set up a thing you want to play with in its own little container on your system, without having to worry about it interfering with anything else you might be doing. Docker lets you go about this in a few different ways. You can go get official images for things (like, say, the latest WordPress install) and do a single run using that image.

Or, if you want to do something a bit more complicated (like, say, running the official WordPress image AND a MySQL image that you’ll need to actually power the WordPress install), you can chain them together using a thing called Docker Compose.

Docker Compose works by you setting up all the config data you need in a file called docker-compose.yml. I’m still fairly new to the syntax this thing requires, but fortunately, I learned a bit about it while I was still at my previous day job at Big Fish. So I was able to utilize that knowledge to build a file that’d let me set up that clean WordPress dev install I want.

I did have to jump through a few hoops to get all the info I needed, though. Here are some pages that proved useful:

So now, as of this writing, I have a nice little set of Docker containers running on my dev box on Linux. And the nice thing about doing this via Docker, especially, is that I could take this exact same docker-compose.yml, reboot my box into Windows, and use it there too. All I need to be running locally is Docker and Docker Compose. The rest of it comes in with the images I specify!

And for the interested, I have checked in my final docker-compose.yml up on my personal Github account, and you can see it right here.

The ongoing quest to get my avians aligned

It’s been a while again since I’ve posted on angelahighland.com. For those of you who haven’t seen my recent annathepiper.org posts (or my posts to social media), here’s a quick overview of what’s been going on in my life lately.

Day Job: I got laid off from the day job at the end of September. I’m still sad about that, as I really loved that job! Since then, I’ve been working on a short-term testing contract while I search for other full time employment leads. This contract job is still in downtown Seattle, but it’s a bit farther south in downtown than I’ve worked before.

It’s also meant that my hours have been somewhat wacky, and I’ve been pretty fried by the time I make it home in the evenings. So I’ve barely had any time to keep up with regular adulting-type things like paying bills. Never mind actually writing anything. That said…

Writing: I’m still working on the next print edition of Faerie Blood. This is something that HAS to happen, given that the espresso book machine I’d been previously using at Third Place to do my print editions is no longer available. Once the day job situation stabilizes, I’m hoping I’ll actually be able to resume work on this. Right now, working on an edit pass seems like it’s more without my power than writing anything new.

(I know I haven’t written anything new in a while, and that DOES stress me out, you guys. But I gotta get my writing mojo back with baby steps, apparently.)

General Site Housekeeping: I had previously tried to spin up sub-sites of my annathepiper.org network, a dev site and a photo site, only to discover that trying to maintain two many different WordPress sites is annoying. So the dev and photo functionality I wanted to do is getting rolled into the general annathepiper.org site.

Angelahighland.com will retain its focus on my books.

For the time being, the bulk of my blog writing will remain on angelahighland.com. Annathepiper.org will get posts specifically related to that site. (This is only relevant to y’all if you’re following my sites directly. If you’re following me on Dreamwidth, you’re going to get both sites’ posts regardless!)

Any questions? How are y’all anyway?

Upgraded annathepiper.org to WordPress 5.0

This is a test, this is a test, this is a test. This is me playing with the new “Gutenberg” editor that comes with WordPress 5.0, and yep, this is sure different.

Gutenberg is oriented around the concept of “blocks”. It keeps offering me things to do to various types of them, including paragraphs and shortcodes. I’m not sure yet if I like this experience yet. But at least there’s a plugin I can install to restore the classic editor if I decide to get rid of this.

For now, anyway, I’ve got this version of WordPress installed on my personal network of sites (which includes both annathepiper.org and angelahighland.com). Assuming nothing obviously explodes, I’ll be rolling it around to the other sites hosted on murkworks.net this weekend.

Rearranging things around here again

I have a tendency to let projects get away from me if I’m not careful, and lately this has tackled me again as I’ve found myself trying to spin off two separate WordPress sites on my network–one for doing indie SDET work, and another for photos. The first was motivated by me getting laid off recently from my long-running day job. The second was brought on by Flickr announcing that they were going to start limiting free users to 1,000 photos and/or videos on their site, which made me think that I might want to move a lot of my Flickr content here.

Both of these projects were nice in theory. But in actual practice, I discovered that having too many WordPress sites to keep track of is annoying for me.

I also discovered that while I liked the idea of a standalone photos.annathepiper.org, this meant that I couldn’t easily get at the photo galleries I wanted to put on it. Say, from pages on the main annathepiper.org site, or old posts. So I’m opting to do the photos thing here instead. And while I think I like the theory of having a standalone dev site on my WordPress network as well, again, I think it’s a bit too much fracturing of how much I need to keep track of with WordPress.

So I’ll be pulling the few posts I put on both of those sites into the main blog on annathepiper.org, as well as the photo gallery plugin I’ve been playing with.

Y’all may also notice that I’ve changed the theme here to WordPress’s Twenty Seventeen theme, since I got tired of looking at Twenty Fifteen, which I wasn’t ever really happy with anyway. And I’ve put up one of my favorite pics as the header. This is my stuffed mammoth Jean-Claude, next to Andre Brunet’s guitar, as taken at Camp Violon Trad in 2017. <3

I’ve taken down the previous menu I had up, as I think about what new things I want to add to it instead. A lot of my older content on this site is stuff I don’t really want to get rid of. But I also don’t want a gigantic menu either!

Anyway. Hopefully this may lead me to actually play with this site more. Let’s see if it does!

(EDITING TO ADD: Hi Dreamwidth people! If you’re seeing this post there, this is of course me talking about rearranging things on my annathepiper.org site, not on Dreamwidth. But the extra bonus of me doing more with annathepiper.org is that you get to see it, too!)