Showing posts with label Complaining. Show all posts
Showing posts with label Complaining. Show all posts

Friday, May 22, 2020

Pholos - Magos Biologis



This Tech-Priest Dominus from 2017 is the first 40K miniature I had done in over 5 years.  My last army were the Heirs of Vulcan, Mega Man-style Space Marines that I never got around to finishing before I sold the lot during spring cleaning.  The new Adeptus Mechanicus minis as well as the hype around 8th Edition finally got me to pull the trigger on more models.

The thing that really hooked me was the change in resources available to hobbyists during my hiatus.  The explosion of high production-quality painting tutorials on YouTube, lead by none other than Duncan Rhodes on Warhammer TV, is what really got me excited to paint.  I assembled miniatures for Blue Table Painting around 2005 which included conversions fed by their huge bitz wall.  But as much as I loved creating a new model, I didn't have the talent for my painting to keep up with my building.  This mini became the gateway to my current hobby enjoyment.  In addition to finding a Bob Rossian Joy of Painting, I have slowed down the rate of purchase, and I have also worked to level up my painting with each mini.  Check out other projects tagged Warhammer 40K for the latest.


The colors reflect the theme of the army.  Verdant green on ripped robes with gold sleeves.  This ragtag assemblage hates the weakness of flesh, and they despise the plants they're turning into war material for the Imperium.  The bottles of unguents keeping them alive are just as sickly green as their robes.

I pushed my skills in terms of layering.  At this point, I was doing no wet blending or even palette mixing.  Following painting tutorials, I applied a base, wash, base again on raised areas, and layers.  The techniques were basic, but seeing the miniature go from grey to painted was transformative.  I settled into a routine of finishing a single color through to highlights with this miniature.  Rather than base-coating everything (and reaching a featureless mini some people call "the ugly stage"), it felt good to practice basic techniques then iterate on the next color.  Before finishing the model, I went back over my novice areas and applied what I had learned.  This one miniature taught me so much about the process of painting.  If you also have a fear of painting, maybe try painting a squad leader before picking up a squad?

The base is a small circular medallion from a craft bin.  The cork and basing material help give it height in the display case without building a whole diorama.  The base is painted with drybrushing.  I finished it with stain after sanding away any stray brown base paint.  The bushes and grass from model railroad supplies.

First Coat

Almost Done

Around and Around

Wednesday, May 20, 2020

Learning AWS - Reflections after a Year in the Cloud

In 2018, a new job for me meant a new tech stack: AWS. Regardless of how long you’ve been developing software, new infrastructure can make you feel like you're starting from scratch. Jumping from a company with a cold room full of mainframes to somewhere cloud native was a shock, but I've enjoyed learning this wide world of cloud^h^h^h^h^hsomeone elses computer. If you feel like a cloud n00b, this post collects tips and tricks for learning cloud development from zero.

As with everything, pace yourself when trying to understand AWS and how to use it. If you feel blocked, put down one service and try another. I have found my happy path is a mixture of study, practical labs, poking around company infrastructure, and handling support rotations. Each contribute, in the long-run, to understanding the available services and building effective products upon them.

The Basics - AWS Vocabulary

The Cloud - Someone else’s computer. Keep this in mind when learning about AWS. It’s all just servers in a data center somewhere else. AWS may take care of a large or small portion of managing these computers for us, and they charge a large or small fee for the privilege.

Identity Access Management, IAM - Amazon’s method of controlling access and permissions to AWS resources. Users can have multiple IAM roles. EC2 Instances use IAM roles. Policies rely on IAM roles to allow/deny access so you only make resources available to those that need to access it.

Regions - A set of AWS data centers that are geographically related but operationally separate. Resources, accounts and VPCs can occupy a specific region.

Availability Zones - Each Region has at least three AZs. Each AZ is a data center separated from others within a specific Region. Each have independent power, cooling, and compute resources to enable you to add fault tolerance to your applications. If internet connections or power to one AZ goes down, you should be able to launch resources in the remaining AZs to compensate for the outage.

Fully Managed Service - AWS services that are fully-managed handle scaling, replication, fault-tolerance and latency without you needing to consider it. A big one is managed Elasticsearch clusters. All you need to do is specify a few parameters and AWS configures the rest (for the most part). Though you don't have to do nearly as much management, learning how to tune managed services is still up to you to solve.

EC2, Elastic Compute Cloud - Virtual machines you can launch on a whim, using the OS you desire, configuring them as you please. This is the backbone of AWS's successes. EC2 is the opposite of fully-managed services. AWS gives you the box, and you do the rest.

Learning Resources

AWS has a host of resources available to help you to learn what options are available. If you’ve never worked with a cloud provider before, I suggest taking some of their video training for Cloud Practitioner Essentials. Login with an Amazon (not AWS) account at https://www.aws.training/. Some trainings include labs that walk you through how to start your own instances, marshal AWS resources, and build a thing for yourself in the cloud. Pick something that matches your skill and engagement level, or use their workshop syllabus to self-guide training.

One of the best ways to learn cloud infrastructure is by doing. AWS offers a massive amount of services at a free-tier. Small VMs, hours of lambdas, and lots of S3 space can be used to learn a service without paying a dime to Amazon. YouTube tutorials about services often are built specifically to never breach free-tier levels of usage. Take advantage of this if getting your hands dirty helps you learn the best. Various online learning companies have video training and integrated quizzes/tests. Some have labs that rely on the free-tier of AWS so you can learn at basically no charge. If you're learning for work, talk to your manager about supporting a subscription if you have a specific avenue of study you want to go down:

If you’re a book person, AWS sponsors official study guides for each certification they offer. These can go out of date fairly quickly, but even an old version will help you get your feet wet when using a prominent service (DNS is DNS, and a Route 53 study guide will be largely applicable next year as last). Check the public library for a guides that will be applicable even if they aren't current. Find a slack channel at work or speak with experienced engineers. Context from experience can break a logjam of misunderstanding faster than reading the AWS docs for the fifth time.

Certifications

The AWS certifications are not required to work with cloud resources, but they can be a big boost to your confidence. If certifications and tests are your preferred method of study, here are a few lines that have been recommended:

  • AWS Cloud Practitioner Essentials - Good overview of AWS resources, administration, security, and budgeting. Take this if you’ve never used cloud resources before and want to come up to speed fast. Available as a series of videos with a free online test for certification.

  • AWS Solutions Architect - This is another broad level of study that can be useful after studying Practitioner. It offers a good overview of current offerings at AWS. You might use some, others not so much. Sometimes it feels like a sales pitch for their managed services, but the curriculum is useful for determining what is possible during the initial phases of a project. The multi-tiered certifications offer a learning path that can scale to your experience and career trajectory.

  • AWS Certified Developer - A deep dive on developing with AWS, the Developer cert study can be helpful in learning how to build on AWS as a developer. The practical labs and study areas cover some of the same problems you might have to solve every day in taking an idea from concept to supportable, sellable, product. This set of certs is also multi-tiered, and it can scale with your own experience if you feel like you need a fresh challenge.

  • AWS Certified SysOps Administrator - Another deep-dive learning path that can help understand how to configure, secure, and economize cloud resources. Covers management and tooling available to keep a cloud running smoothly and safely without breaking the bank. Also has multiple tiers of certification.

Yarn Pet Mod - Platform for One Pound Cakes



My roomate has been picking up knitting and expanding their crochet skills during the pandemic Stay at Home orders.  As a part of their stimulus, they bought a Yarn Pet from Nancy's Knit Knacks.  They have also acquired a yarn ball winder that claimed to be able to do one pound skeins.  The curlicue tensions the yarn as it unwinds from the outside of the cake.  The platforms that came with it were thin circle platforms afixed to a smooth metal spindle with stops and set screws (you can see the spindle and stops above).  The platform holds the cake above the base at the appropriate height for the curlicue.  Small cakes?  Set it high.  Big cake?  How low can you go!

When they actually tried to use the Yarn Pet with the largest cakes (Caron One Pound FTW!), the little platform circles that came with the pet allowed the cake to slump and sag.  The cake would also rub against the curlicue and made it hard to pull.  They were worried about the yarn slipping below the edge and tangling under the cake.

To fix this, I used a board as wide as I could get and made it a circle:
  1. Found a home depot pine board in my scrap bin that was 5 3/4" wide.  Solid wood is preferable to plywood which can get splintery and snag the yarn.  Avoid knots if at all possible.
  2. Cut length to match width.
  3. Find the center by marking two lines from corner to corner
  4. From center, use a protractor to mark 22.5 degree increments to the edge.
  5. Drill a hole in the center mark.  To fit the Yarn Pet spindle, I needed a bit with a width  7/32".
  6. Using a table saw with miter gauge set to 45 degrees or a miter box, cut your square into an octagon
  7. Test your new platform on the spindle.  My square was about a quarter inch too wide at the widest point, but it had plenty of play between a flat side and the curlicue.  I knew trimming it again would allow it to spin freely.
  8. I trimmed my octagon into a hexadecagon by setting my gauge to 22.5 degrees.  (Towards the end of the piece, the side touching your miter gauge will be incredibly small.  Keep a firm grip, and beware of kickback!)
  9. Sand the tarnation out of every surface with 150 up to 220 grit.  You can see in the picture above that I rounded every edge and corner.  I chose not to finish the wood, but I can always go back and do this between knitting projects.

Things learned:
  • I thought the thickness of the platform might be an issue, but it turned out to be perfect for giant cakes. The added thickness prevents the platform from wiggling on the spindle.  You can plane down your board to match the included platform circles, but then I might be worried about their integrity.  As is, the yarn comes off cleanly with the center-line of the cake coming just above the curlicue.  So smooth...
  • When putting the largest cakes on the pet, use the rubber stoppers for spindle-wound skeins to keep the cake centered on the spindle.  This will prevent wobbling due to a loosening center as it is pulled from side to side.
  • If you have a circle of the appropriate width and thickness already, all you need to do is find the center and drill it.  Couldn't be simpler.

Thursday, April 23, 2020

Taming an AnyCubic Kossell Pulley 3D Printer

Quick post to note how I got my Anycubic Kossel Pulley basically working.  It took me forever to find how to do some of this, and I know I will forget it if I do not write it down.

  • Use DaHai's configuration video for starters.
    • Upgrade the firmware to Marlin 1.1.9.  I ended up using 1.1.9.1 as of this writing.
    • Use DaHai's files and modify them to work with stock Steppers.  Use Arduino IDE to load the firware after replacing Configuration.h and Configuration_adv.h (which I did not make changes to).  Here are the changes I made to his Configuration.h:
      • Line 624-626: Change these from his upgraded TMC2130_STANDALONE to stock A4988
      • Line 705: I got crazy loud stuttering when first descending to the bed during a print.  Lower this to get rid of that.
      • Line 868: I and several people online have measured and gotten good resulting prints with the Type 2 Probe Offset at -15.88
      • Line 938 to 940: These need to be true for stock steppers.  DaHai's steppers did not need to be inverted.
      • Line 1358-1364: Define your temperature presets. I have used PETG to great success with a preheat of 70C for the bed and 230C for the hotend.  This rises to print at 80C and 245C respectively during the print.
    • When following the leveling instructions, the video shows a "Set Delta Height" option that is absent in the version of the firmware I loaded.  This caused me no end of headaches later when the method of subtracting the bed distance from both the Z-Height and Probe Offset produced weird math and never worked properly.  Instead, I ran auto-calibration, saved the settings, then:
      • Noted my Z after going to Prepare -> Auto Home
      • Brought the nozzle to the bed using Prepare -> Move Axis -> Move Z until a business card wouldn't move when squished between the axis and the bed.  I then noted the height
      • Changed my Z height only by this amount by subtracting the number from the Z height, and a negative Z Height is thus added.
      • Saved and Auto Homed
      • Set my Probe Offset to 15.88 per recommendations online.
      • Checked it again and only touched the Z Height when it was off.  Repeat the Z height move if this is still not right.
  • With the printer calibrated, it was time to print.  I just used Cura because I couldn not get Slic3r or Pronterface to work easily.  Cura does not have the Kossel in it by default, but it can be easily added.  JDHarris on Thingiverse even shared the configuration file they made which can be picked up by Cura after a restart.
  • I printed with PETG which has a high temp but no fumes.  I found hairspray for adhesion worked best thanks to several awesome tips by people connected with the PDX hacker community.  Thanks all!
After this, it just worked and keeps working.  It's magical what a little math and open source firmware will do.  That being said, it's my first printer.  It is bound to break in ways I can't even imagine now.  First order of business?  Print things that make the printer better, as is tradition.

Update: Not all is well in Whoville.  I've developed some Heat Creep with this PETG printing at 245C, and I haven't had the time to troubleshoot it.  Wish me luck!

Wednesday, January 22, 2020

New Year, New DEF CON

During the DEF CON 26 DC101 Panel, someone (probably highwiz) asked one of the n00bs they brought on-stage, "What makes you a hacker?" In the past, it has been used by bad actors as an aggressive question.  Thoughtful types and artists have used it as a prompt.  But here it was dripping with curiosity.  "Why do you go to DEF CON?"

I'm more than a year out from a move that took me far from my hometown of Las Vegas to an adventure into the Pacific Northwest.  Budgets, family and time being what they are, I too had to ask myself, "What makes you a hacker?  Why should you go to DEF CON, again?"  Obviously, moving two states makes it harder to go.  Plane tickets are cheap enough in cattle-class, and I'm lucky to have family and friends in town upon which I can rely for lodging.  But family illness and obligation are also considerations, and this feeling in the pit of my stomach topped it all off: the idea that I no longer belonged.

Ironically, this security-focused community is affected by deep insecurities.  Concerns of legitimacy, competence, and belonging haunt us collectively, as do public examples of snake oil, burnout, and depression.  Discussions of Impostor's Syndrome are almost cliche in their frequency.  As is the mouth-agape disbelief following one of our rock stars admitting they second-guess themselves.  This loose band of social misfits and punks emerged from in our cocoon of BBSes and IRC to be famously dysfunctional. We have had to exorcise #MeToo demons, and our unhealthy relationship with alcohol keeps many away for fear of their own safety.  As a late-comer to DEF CON, I have not been personally affected by loss of friends in the community, but there's a reason Amber Baldet gave a talk on Suicide Interventions at DC21.  Hackers in my cohort are maturing as well.  Some of us are on their third career since the demoscene, and it has veered wildly away from any Information Security role.  There has to be something that keeps us coming back to the desert in August.  It sure ain't the unmistakable fragrance of Sunday morning talks.

It is a bit of a balancing act to maintain a conference that keeps drawing more and more people.  As of this writing, DC28 is scheduled to use almost 400,000 sq. ft. of conference space in a brand new facility.  Almost 30 villages with both broad and niche topics have formed, and each is a mini-con in and of itself.  Along with this widening scope, there were public and repeated attempts by The Dark Tangent to reestablish DEF CON as a Hacker event and set it apart from the Information Security industry where so many of its attendees find employment.  In the past, DT has publicly disinvited the Feds, and the run-up to DC27 saw another public clarification that while individual villages arrange their own sponsorship, DEF CON maintains no corporate sponsors.  You can see the push and pull of "What makes you a hacker?" at the highest levels.

And so we approach a new year and a new DEF CON.  Since DC19, I've grown with the conference.  I started managing Toxic BBQ with the help of friends and this will be our fifth consecutive kick-off barbecue.  People just show up to create an inviting space from scratch for anyone that can find it.  I won a Black Badge with my son at DC 26 by solving crypto puzzles and have tried to contribute in equal measure since then. And yet there's this nagging feeling...

Ultimately, I've decided the gate-keeping question is not an important one to answer.  What I give to and get from DEF CON keeps me going.  I'm comes down to a desire to think things I have never thought before.  I may not be able to show off like some, but I can gawk with the best of them at the Hacker Carnival.  DC28's theme, Discovery!, is right out of my high school years when the internet promised the sum-total of human knowledge at our fingertips and all that we could do once those barriers dropped.  Maybe we can celebrate by shedding our insecurities.  Just for the weekend.

Sunday, March 24, 2019

Dan Moves North

Plenty has gone on in the past year. Here's a quick rundown:

- Learned how to quilt. 104 patches from my tour-guiding days on a lap quilt.




- Learned how to Black Badge at DEF CON 26. Shout out to my fellow Murder Hobos, PunkAB, and the entire Dungeons@DEFCON team for this kick-ass experience.













- Learned how to move across country through forest fires and with cats









- Learned how to survive a leg infection possibly from a cat scratch (not pictured; it was pretty gnarly)

- Learned how to not buy board games. I finished a 10x10 (play ten games ten times or more) without buying any new games in between. Moving thinned the collection, but it still takes up an entire linen closet.




Tuesday, June 12, 2018

Quotes from Dan Kaminsky's Keynote at DEF CON China


Above is Dan Kaminsky's keynote at the inaugural DEF CON China.  It was nominally about Spectre and Meltdown, and I thought it was immediately applicable to testing at all levels.  Here are some moments that jumped out at me:

On Context:

"There's a problem where we talk about hacking in terms of only software...What does hacking look like when it has nothing to do with software." 1:55

"But let's keep digging." Throughout, but especially 5:40

"Actual physics encourages 60 frames per second. I did not expect to find anything close to this when I started digging into the number 60...This might be correct, this might not be. And that is a part of hacking too." 6:10

"Stay intellectually honest as go through these deep dives. Understand really you are operating from ignorance. That's actually your strong point. You don't know why the thing is doing what it is doing...Have some humility as you explore, but also explore." 7:40

"We really really do not like having microprocessor flaws...and so we make sure where the right bits come in, the right bits come out. Time has not been part of the equation...Security [re: Specter/Meltdown] has been made to depend on an undefined element. Context matters." 15:00

"Are two computers doing the same thing?...There is not a right answer to that. There is no one context. A huge amount of what we do in hacking...is we play contexts of one another." 17:50

[Re: Spectre and Meltdown] "These attackers changed time which in this context is not defined to exist...Fast and slow...means nothing to the chip but it means everything to the users, to the administrators, to the security models..." 21:00

"Look for things people think don't matter. Look for the flawed assumptions...between how people think the system works and how it actually does." 35:00

"People think bug finding is purely a technical task. It is not because you are playing with people's assumptions...Understand the source and you'll find the destination." 37:05

"Our hardest problems in Security require alignment between how we build systems, and how we verify them. And our best solutions in technology require understanding the past, how we got here." 59:50

On Faulty Assumptions:

"[Example of clocks running slow because power was not 60Hz] You could get cheap, and just use whatever is coming out of the wall, and assume it will never change. Just because you can doesn't mean you should...We'll just get it from the upstream." 4:15

"[Re: Spectre and Meltdown] We turned a stability boundary into a security boundary and hoped it would work. Spoiler alert: it did not work." 18:40

"We hope the design of our interesting architectures mean when we switch from one context to another, nothing is left over...[but] if you want two security domains, get two computers. You can do that. Computers are small now. [Extensive geeking out about tiny computers]" 23:10

"[RIM] made a really compelling argument that the iPhone was totally impossible, and their argument was incredibly compelling until the moment that Steve Jobs dropped an iPhone on the table..." 25:50

"If you don't care if your work affects the [other people working on the system], you're going to crash." 37:30

"What happens when you define your constraints incorrectly?... Vulnerabilities. ...At best, you get the wrong answer. Most commonly, you get undefined behavior which in the presence of hacking becomes redefinable behavior." 41:35

"It's important to realize that we are loosening the assumption that the developer knows what the system is supposed to do...Everyone who touches the computer is a little bit ignorant." 45:20

On Heuristics

"When you say the same thing, but you say it in a different time, sometimes you're not saying the same thing." 9:10

"Hackers are actually pretty well-behaved. When hackers crash code...it does really controlled things...changing smaller things from the computer's perspective that are bigger things from a human's perspective." 20:25

"Bugs aren't random because their sources aren't random." 35:25

"Hackers aren't modeling code...hackers are modeling the developers and thinking, 'What did [they] screw up?' [I would ask a team to] tell me how you think your system works...I would listen to what they didn't talk about. That was always where my first bugs came from." 35:45

On Bug Advocacy

"In twenty years...I have never seen stupid moralization fix anything...We're engineers. Sometimes things are going to fail." 10:30

"We have patched everything in case there's a security boundary. That doesn't actually mean there's a security boundary." 28:10

"Build your boundaries to what the actual security model is...Security that doesn't care about the rest of IT, is security that grows increasingly irrelevant." 33:20

"We're not, as hackers, able to break things. We're able to redefine them so they can't be broken in the first place." 59:25

On Automation

"The theorem provers didn't fail when they showed no leakage of information between contexts because the right bits went to the right places They just weren't being asked to prove these particular elements." 18:25

"All of our tools are incomplete. All of our tools are blind" 46:20

"Having kind of a fakey root environment seems weird, but it's kind of what we're doing with VMs, it's what we're doing with containers." 53:20

On Testing in the SDLC

"We do have cultural elements that block the integration of forward and reverse [engineering], and the primary thing we seem to do wrong is that we have aggressively separated development and testing, and it's biting us." 38:20

"[Re Penetration Testing]: Testing is the important part of that phrase. We are a specific branch of testers that gets on cooler stages...Testing shouldn't be split off, but it kinda has been." 38:50

Ctd. "Testing shouldn't be split off, but it kinda has to have been because people, when they write code, tend to see that code for what it's supposed to be. And as a tester, you're trying to see it for what it really is. These are two different things." 39:05

"[D]evelopers, who already have a problem psychologically of only seeing what their code is supposed do, are also isolated from all the software that would tell them [otherwise]. Anything that's too testy goes to the test people." 39:30

"[Re: PyAnnotate by @Dropbox] 'This is the thing you don't do. Only the developer is allowed to touch the code.' That is an unnecessary constraint." 43:25

"If I'm using an open source platform, why can't I see the source every time something crashes? ...show me the source code that's crashing...It's lovely." 47:20

"We should not be separating Development and Testing... Computers are capable of magic, and we're just trying to make them our magic..." 59:35

Misc

"Branch Prediction: because we didn't have the words Machine Learning yet. Prediction and learning, of course they're linked. Kind of obvious in retrospect." 27:55

"Usually when you give people who are just learning computing root access, the first thing they do is totally destroy their computer." 53:40 #DontHaveKids

"You can have a talent bar for users (N.B.: sliding scale of computer capability) or you can make it really easy to fix stuff." 55:10 #HelpDesk
"[Re: Ransomware] Why is it possible to have all our data deleted all at once? Who is this a feature for?!... We have too many people able to break stuff." 58:25

Tuesday, April 3, 2018

Urns

My father passed late last year, and I made three nondescript urns as keepsakes for family and friends. It was the first time I made a box of any respectability since 2000.  I hadn't originally planned to make them when he passed, but making them helped me process things in a difficult time.

I was the responsible party for my father's estate as his wife does not speak English very well. As such, it fell to me to arrange the funeral, notify friends, and start to organize his affairs. I kept it together. The arrangements were made, the bills were covered, and all in a few days. I kept it together, that is, until I tried to return to work. I got ready. I even got in my car to go. But I could not. Instead, I went into the shop and executed a simple design for holding a portion of his ashes.

The material is Indian Rosewood (the same that I used for the magnetic bottle openers). The strong grain made mitered corners a natural choice. I even had enough contiguous grain to try to book-end most sides. I didn't have a keyed or splined miter jig (which could have strengthened the corners), but I figured the lid and bottom would provide a good brace against failure.

Dimensioning the lumber wasn't very difficult; it was the geometry of the corners that caused me real trouble. I left the sides thick to give each box some heft. I eyeballed the lid thickness and shaved down some beautiful figured grain to just the right height (maybe I overshot it a little and had to clean it up later). When I got to cutting the miters, I found that I didn't have any accurate way to match them up. The miter saw was definitely not accurate from cut to cut. I lost a lot of material on the table saw trying to get a canted blade to just the right angle. I finally settled on using my miter sled. I had to cut the sides down a bit to make sure I could make the entire cut in one pass. By the end of this therapeutic day, I had three roughly identical boxes ready for glue-up.

The second half took a few more months to pull off. Uncertainty about the accuracy of the cuts lead me to put the project on hold. Should I delay and try to true then with a shooting board? My girlfriend gave me the most wonderful advice once: when you find yourself rushing a project, put it down and come back later. The parts to three urns marinated on the bench and in my mind for a few months.

A test fit in March didn't seem too bad. The time off convinced me to persevere and get them together. I discovered too late that I mixed up the orientation of the edges. My careful bookends were a jumble on two of the three boxes. However, the imperfect corners and dimensional problems worked to hide the errors amongst each other. Sanding trued up protruding tear-out and splinters without obvious rounded-off corners. Finally, dark stain and some paste wax finished the work of hiding imperfect joints in dark recesses and shiny polished surfaces.

I finished the bottom with plywood. If I had to pick a spot where I'm uncertain about my choices, it's here. Glue is strong, but how will the baltic birch bottom hold up over time? I'm thinking of throwing in some brads there just in case. The bottom served as a canvas whereon I could memorialize my father. I was able to burn the message "Invictus Maneo", the Armstrong Clan (and our ancestral) family motto. Loosely translated, it means, "I remain unconquered."

This entire project was an object lesson in how I'm still learning some of the most basic techniques in woodworking. I need a way to clean up miters that start on the saw. A shooting board or similar has been recommended. Fine adjustments on my existing miter sled might also work. Though it didn't seem too bad once finished, the tearout for certain cuts makes me think I have a dull blade. I'll have to investigate, tune, and try again.

I think I've worked through a phobia of complex geometry. Something my father always talked about is how to hide your mistakes in woodworking. Bookends, miters, and a fitted lid left precious room for that, but I found a few tricks along the way such as meticulous test fitting, blue tape as clamps for difficult pieces, and patience above all. Regardless, I'm looking forward to the next boxes I build. I hope those have a markedly different emotional footprint.

Sunday, September 24, 2017

Dan Learns How To Blog...

Here's a quick retrospective after 25,000 page views.  In 4 years, topics were all over the map.  Mainstream topics like hacking Skylanders brought organic traffic from search engines.  Posts in a niche subreddit has a way of bringing in links years on.  The Cards Against Mormonism and boardgame tables still get a few hits per week.

Advertising revenue was an interesting experience.  A free site has generated a whopping $10 in 4 years from Google, and I haven't seen a cent from Amazon referrals.  In all, it's interesting to see how hard it would be to make a living with just ad revenue.  Sponsorship makes a lot more sense in this light, but impartiality takes a hit.  The web runs on a sea of quid pro quo.

In terms of authoring content, I learned a few things that English class couldn't anticipate in 1999. Mentioning specific dates instead of relative dates keeps readers from having to calculate in their head and increases the possibility that they will stay for the whole article.  If you have a story idea that has been sitting in your drafts for more than 3 months, delete it.  Your enthusiasm to talk about it is probably not going to grow after that long.  Build logs and multi-part posts should be split into shorter posts.  This will ensure you stay on topic and don't ramble.  And don't talk about how long it's been since you last blogged.  I can assure you that no one it waiting with bated breath for your review of Behat's 3.4 release.

On to the next 25,000!  Hopefully it won't take me 4 years.

Tuesday, August 11, 2015

Responding to Vulnerabilities and Weaknesses in your Product: A Tester's Perspective

Compare and Contrast: Tesla's response to researchers: 

With Oracle's: 

To be fair, no company should have to sift through an automated report from a static analysis tool.  It’s not worth their time.  In fact, the tone of the Oracle Blog that isn’t completely unproductive is, “Do the research for yourself!  Give me exploits or give me death!”  As a Tester, this is the core of bug advocacy, and I want to destroy the trust lazy researchers put in automated scanners, lazy managers put into automated checking, and the lack of human interaction endemic in development in general.


That being said, chiding someone for spending their own coin to find a exploit with, “But you really shouldn’t have broken the EULA.  Nanny Nanny Boo Boo,” is unproductive at best and an invitation to become the target of malicious actors at worst.  No one cares about your EULA.  Not even the government gives it the time of day.  Your tantrum just makes that many more people want to do things to piss you off.

Monday, February 16, 2015

The Uncanny Valley of User Interfaces

Of all the things to get peeved about, you wouldn't think commercials would be one of them.  In spite of avoiding commercials by cutting the cable cord, I have found myself employed at a place that runs ESPN 24/7.  While it's not as bad as commercials on Fox News, certain commercials have begun to irk me for reasons that only a software guy can understand.  In general, I believe this revulsion can teach us how to test user experiences.

To start, allow me present two exhibits: Jillian Michaels for Nordic-track and Trivago Guy for Trivago.  Have you watched them?  Good.  Are ads for them already populating your sidebar?  Allow me to apologize.  So, did anything bother you?

Now, here is a second exhibit: Fiddler on the Roof.  I'm sorry if I ruin this for you, but the fiddler is not actually playing his instrument.  In high school, I saw this movie once in class, and again after I spent a year in orchestra.  The second time through, I knew as little about playing the violin as one can, and it still bothered me that the fiddler wasn't successfully playing in sync with the music.  The distraction caused by bad miming is well documented.  Recent Amazon series Mozart in the Jungle has it.  Other movies aren't immune either.  Even a talented musician can be affected by it without equal attention to production (try not to notice the out-of-sync miming and white truck in the background 52 seconds in).  The core problem is that you need to train someone who is good at acting to fake a highly skilled activity convincingly enough to keep the audience's focus.  If the audience knows even a little, their belief is unsuspended, and you can lose all credibility.

Normally, this is fine.  in a two hour film or season of a television show, the viewer is pulled in by the drama.  The story isn't about how well the artist can play the violin; it is about the character's story. Also, most directors can rely on the majority of their audiences not knowing what skilled activities like playing the violin and hacking actually look like.  Camera tricks can make some instruments easier to fake than others.  Furthermore, some miming has become acceptable and celebrated through parody.  We know it's hard to convey on film.  Should that mean we don't tell this story?

Unfortunately, there is a class of film that cannot rely on the social contract to ignore non-experts acting out difficult skills.  Its short format leaves no time to pull a person back in after having been jarred from their witless stupor.  What pitiless medium is this?  Commercials.  In 30 seconds or less, the disingenuous spokesman is called out.  The thankless medium that pays for most of our entertainment is reviled for cheesy effects, leaps of credulity, and now one more heresy: poorly mimed user interfaces.

Let's return to our exhibits, shall we?  Nordic-track wants to sell us another piece of exercise equipment that we will only use as long as we are paying for it.  To do this, they've strapped on a touchscreen to navigate workouts.  What does Jillian Michaels use to navigate?  Two fingers, and she watches the screen as she swipes left.  Thinking back to your own interactions with iPads, touchscreen kiosks and mobile phones, when have you ever watched the old screen disappear?  And when have two fingers ever been used to navigate a touchscreen?

The second is Trivago Guy.  Not only has he drawn attention for being creepy, but his ham-handed interaction with the user interface makes me cringe.  Poking at points on a calendar, full-handed presses of the Search button, and similar miming make me look up from my desk and gag.  Similar interactions with after-effects like those in the Endurance Extended Warranty commercial make me wonder if anyone thought to proof the commercial before buying ad spots day after day, year after year.  An alternative explanation would be that the producers honestly think this is the way people interact with computers.  Either one disarms the viewer and places the product as unfavorable in their eyes.

I would like to propose that each of the above cases can be grouped together as potential examples of the Uncanny Valley.  As a movie viewer familiar with how a violin is played, I connect notes and the movement of bow in a way that the uninitiated cannot.  I reject the characterization as invalid for a brief period, but my emotions pull me back in with other human interactions elicited by the actor's performance.  For these commercials, this does not happen.  The terrible user interface interactions remove focus from the message of the commercial, and it is judged as unfit just long enough that I reject the product on offer.  Worse, subsequent viewings reinforce my first impressions.

Generalized lessons in the User Experience design space are many.  After testing a new user interface, I have found it helpful to let the uninitiated take it for a spin.  While I have been long-desensitized to bad interaction by other considerations ("It actually works once you get used to it!" being one, "I just want to be done with this." being another), initiates see the unnatural interaction, and one can read the revulsion in their face even when they don't come right out and say it.  This commercial for the new product is a failure, and I don't wait around to see them lulled into the same sense of security.  It stinks, they know it, and now I do to.  While users might not be expected to use a new interface right away, something that is counter-intuitive from the start should be avoided.  Depending on the medium, counter-intuitive steps can be overcome, but not without good decisions elsewhere to draw the user back in.

Tuesday, January 6, 2015

Context-Driven Testing, An Education

Coming into my fifth year of Software Testing, I began to rethink it as a discipline. The current debate is between traditional methods of testing and more modern schools of thought:
  • Entrenched methods are represented by the International Software Testing Qualifications Board (ISTQB) and its many local equivalents. Certification is their path to expertise, with accompanying wares of training sessions, books, tests and standards.
  • Context-driven Testing focuses more on a set of tools and skills that typify testing.  Advocate offer classes at conferences, but certs and best-practice are four letter words.  They state that there are no best practices, and a tester knows best how to apply the tools to explore, experiment and learn about the system under test.
The conflict seemed from the sidelines like a pitched battle over the future of testing. The ISTQB and affiliated consultants had history and 300,000 certifications on its side.  The context-driven school was relatively young, but it had a few charismatic evangelists and professional results that could not be ignored.  It was plain that I needed to sort this out.

Something Just Didn't Feel Right

I strode onto this battleground in 2011 as a new manager and new tester.  Promoted from an application integration team, I was used to working with outside developers while using and abusing buggy product.  This did little to prepare me for the reality of testing: limited time and endless defects!  I dove into the online community in the hopes that it would help sort the good from the bad.  What I found to be the central influences were conferences, consultants and blogs.

At testing conferences, half the talks were advertisements for bug trackers, test case repositories and automation frameworks.  These were great for managing a project, but they didn't support the essence of testing: finding more defects.  Expensive tutorials before the conferences showed similar taint: how to use this tool, best practices for testing this specific type of thing, certification in a process and not a portable technique.  The cost was the most surprising thing: Thousands of dollars for something I couldn't justify to myself, the eager tester with a training budget to burn.

Delving into webinars brought more despair.  A demo of the latest automation tool invariably lead to a pitch to get me to purchase something.  The topic purported to discuss principles, but I ended up in the morass of industry jargon.  I learned how to write, automate, and justify my time, but I was no closer to actually finding bugs in a more efficient manner.  And what's more, I was spammed by vendors for months after.  I found zero techniques that were universal.

Finally, the blogs showed a glimmer of hope.  Some people wrote about techniques.  Others wrote about test cases and how they managed their overhead.  Still others advocated that QA should be involved earlier in the development process.  Nowhere did anyone extol the virtues of their test management system, bug tracker or automation too in helping them find bugs.  This was a breath of fresh air, but it still felt stunted and directionless.  My closest analogue, software development, spawned a generation of people applying agile to everything from families to manufacturing, but there wasn't a similarly powerful framework for testers.  I started to feel that no one was excited about my new career outside of the context of getting paid for it.

This muddled world left me questioning: Shouldn't there be some "ethos of testing" to unify our efforts just like in agile software development, lean manufacturing, and so forth?  Why do vendors have a place at the table at industry conferences?  Why isn't anyone embarrassed that the main competitor to major test management software is a spreadsheet?  Who cares about my expertise and not just my dollars?

"Answers" and Answers

For a long time, I thought the answer was in certification.  Surely, if ever there was an organization that could be a cheerleader for quality, it would be the ISTQB.  However, the reality is much different.  Manuals are filled with process, conferences host vendors and not practice sessions, and training classes are about extracting fees and not learning techniques.  The certification exam that guarantees your resume goes to the top of the pile and organization that proctors it is a laughing stock.

The alternative came through an unlikely route: Twitter.  Long a tool of celebrity publicists and companies looking to engage directly with individuals, Twitter also has a reputation as the way to communicate within a subcultures.  Have an idea?  Publish it in under 140 characters.  Want to learn the pulse of an industry?  Follow its leaders.  Computer security wonks, hackers, and now testers joined my follow list, and I was soon introduced to a new debate: is certification a waste of time?  I'd found my people.

The new school touted something called Context-driven Testing.  Instead of best practice, effective testing was supposed to be driven by context.  Instead of test cases, a set of tools were taught that could be used depending on the product (mainframes are tested differently than mobile devices).  Even among superficially similar products, the most effective testers would make judgement calls based on the needs of the customer and the time available.  Testing was not a set of rigid processes, but a scientific exploration of the software.  The knowledge gained by testing increases the confidence of the organization in the software.  In other words, testing challenges the assumptions made by the developers that the product works in the time we have available.  This sounded like the meat I was looking for, but the results were amazing too.

In an experiment, I had our work study group put down the ISTQB manual with its test cases, and I instead introduced them to exploratory techniques.  We first learned about the requirements and returned a bunch of questions to the developer.  Then we tested without scripts and tracked our coverage on a mind map.  It was the first time we had been prompted to field trial a technique in our study session.  The best part was that a person with very little previous experience in testing was able to pick up the technique almost organically.

This revelation about software testing was what we were all looking for, and it was delivered through experience instead of pronouncement.  James Marcus Bach, one of the proponents of Context-driven Testing compared the ISTQB and certification organizations to the medieval medicine of Galen.  People wrote down what testing was and proceeded to bleed their employers without knowing why it wasn't finding bugs.  Testers were outsourced instead of valued as their techniques were old or ineffective.  Yet in spite of all this, the consultants and conferences kept making money printing outdated works of questionable value.  Once context-driven techniques come to light, the old ways start dying.  We can only hope this continues so that meaningless certs are no longer valued by testers, managers and HR alike.

Where Next?

After stumbling through the world of testing for a few years, I have abandoned certification as a path to expertise.  As with computer security, network administration and technical support, certifications are a poor way of communicating true expertise.  This revelation places testers firmly in the camp of indispensable elements of the development organization.  They are not monkeys running scripts but knowledge workers with a valuable investigative skill that challenge the product from all angles.  They cannot be outsourced if you hope to be successful, and they cannot be replaced by automation.

I am beginning a new training regimen with my testing colleagues based around Context-driven techniques.  We hope to learn the techniques and apply them to our current projects and continually grow our skills in this new framework.

Further Reading


  1. A Context-driven Testing manifesto of sorts
  2. Black Box Software Testing, Coursework in Context-driven Testing
  3. Rapid Software Testing, James Marcus Bach's courses on Context-driven approaches:
  4. Exploratory Testing techniques explained
  5. Testing is not Automation.  Why Automation is another tool and not a cure all.

Monday, December 8, 2014

Clark County, Nevada Elder Abuse Resources

I was concerned for the safety of a family member who is older not long after their spouse passed away.  Below are some things I learned about Elder Abuse, the resources available to help those in need (individuals or family), and things to do when investigating elder abuse.

Before going nuclear on someone new in your relative's life, first do the single most important thing: talk to your older relative.  Often, misunderstandings or matters of privacy can be sorted out without resorting to law enforcement, state assistance or subterfuge.  The matter of trust between you and your relative is the single most important factor in maintaining their long-term health and well-being.  If you lose their trust, you lose almost all ability to help them.

Local Police Resources

Police seem to only be able to make 'welfare checks' for elderly people that outsiders suspect are being abused. They can only visit the premises when the person is home. The Las Vegas Metropolitan Police Department Operator and Dispatch informed me that there are dedicated Elder Abuse detectives. Unfortunately, they only operate M-F, 7-4. As the crisis was after this time, we couldn't get a welfare check immediately. The numbers for these departments are below:
  • Metro Operator: 702-455-8697
  • Metro Dispatch 702-828-3307
  • Elder Abuse Detectives: 702-828-3111 (Hours are 7-4, no voice mail)

State Resources

Though I I have not taken advantage of these resources, there may have been help available through the Aging and Disabilities Services connected through the county. Comparable services may exist locally in your neighborhood.  Perhaps there are some interventions that would be helpful going forward?

Social Engineering

When trying to find out more about people that have entered a loved one's life unexpectedly, unexpected phone calls from unknown people are a great source of more information.  Generally, act as if the person is at home but not available.  The person on the other end of the line may divulge information that gives you clues about the intruder.  Effective phrases are below:
  • "Yeah, he's here but he's busy.  He asks what you need."
  • "Hold on, let me get her...She's here but can't pick up right now."
  • "Who is this again?  I didn't get that down last time."
  • "His phone is dead.  What number can he reach you at?"
  • "What was it again that you're meeting for?"
While the person is out, check the circumstances of the house, but try not to disturb things too much.  Look for signs of drug abuse, behavior you know your relative would frown upon such as smoking and drinking in the house. If you know their location, ensure firearms are secure, and check the status of belongings, heirlooms and money caches.  Document and narrate your search by video.

If you must get the police involved, minimize the impact on your relative.  See if they will come around when you try to have a person escorted off the property.  Ensure your relative is not involved in any illegal activity before involving the police, and, most importantly, get the consent of your relative before escalating.  You must maintain their trust, and asymmetric reactions to otherwise benign or diffusable situations can ruin that bond and expose a vulnerable relative to harm from both the intruder and the police.