View on GitHub

Quorten Blog 1

First blog for all Quorten's blog-like writings

One important design consideration of my 3D scanner design that I didn’t consider is motor vibration control. Particularly, in the case of using cheap DC motors, you’re going to get vibrations traveling away from the motor due to not being perfectly weight balanced, imperfections in the design of the motor, a shaft that is not perfectly aligned, different force responses based off of the relative positions of the rotor and stator, and so on. Most importantly, these are qualities endemic to the motor, independent of the rest of your setup. But, when those spurious vibrations travel from the motor to the rest of your setup for rotating the laser module, those extra vibrations in your laser module effectively limit the maximum resolution that you can scan at, potentially even more so than the width of your laser.

So, what can you do about this? It could just as well be the case that using your average stepper motor in place of your average DC motor could solve your motor vibration woes. Especially considering some of the design specifications and measurements made for the FabScan 3D scanner, indeed a stepper motor can get you pretty good accuracy and minimal spurious vibration out-of-the-box.

Read on →

So, you’re wondering. What exactly are the uses and differences between wave soldering and reflow soldering? Well, first of all, wave soldering is typically used for through hole components, and reflow soldering is typically used for surface mount devices. Second, all bets are off that you can mix and match both of these. You can attach surface mount devices using reflow soldering, and you can attach through-hole devices using reflow soldering. That being said, if you want to attach surface-mount devices using soldering paste to a PCB at home, you can do it with a low-end soldering pencil iron. Simply use the soldering iron to reflow the solder paste, or use conventional solder directly if you really think you can do it.

Now, there are also some interesting tricks for desolering. Sometimes a hot air gun is used for desoldering. For this, you might try to substitute a blow dryer. Another interesting technique is to use a wire of Field’s metal to wrap around a surface mount device to distribute the heat, heat that wire up, and you’ll be able to pull the surface mount device right off, keeping both the device and the board intact.

20181214/https://en.wikipedia.org/wiki/Wave_soldering
20181214/https://en.wikipedia.org/wiki/Reflow_soldering
20181214/https://en.wikipedia.org/wiki/Desoldering
20181214/https://en.wikipedia.org/wiki/Field%27s_metal

Where do you store your photos that you use for your blog? Well, I don’t have a complete answer to that question, but I do have a part one answer to that question. Suffice it to say, photography is a much different endeavor than blogging. Whereas the text of blogging is typically of human authorship, the articles that you hand-craft and shape as you please, photography is a bit different. Photography is a statement of how the world appeared from a particular device, at a particular time, at a particular location. That being said, it makes sense to store all photos under that organizational guise.

  • Footnote: Renote, I searched for this and found it, that means it’s important!

So, then, what about photos for your blog? Naturally, those first premises mean that blog photos should be linked from an external source. Diagrams, by contrast, are very dissimilar to photos and more similar to the text of a blog in that a diagram is hand-authored by you, and possible to reproduce by hand, just like the text of the blog articles you type. Photographs, by definition, are beyond human hand reproducibility. Where you store those photos, it’s got to be on some more general purpose photo storage server, and that is what I leave uncovered as a part two step.

So, I guess this brings up another important point in hand. If you have a photo in your blog article, it better not be in any way the sole source of some important information. There has to also be a simple, purely hand reproducible diagram accompanying the photo.

Now, this is interesting. In the history of some large enterprise software companies, there were some features that they really wanted to retire from their products, but the first few couple of times they tried to retire it, one of their big corporate customers paid them to keep it going, so they changed their mind and accepted the money. Now, quite intuitively, we can know that this is wrong, but the question is how do you firmly say “no” to those customers?

First of all, you have to remind yourself think about why you wanted to deprecate that obsolete feature. The obsolete feature no longer makes sense in the modern world because it’s just yet another way of doing things. The feature was originally developed because it was thought that nothing else existed at the time. But, in the modern context, a much more mainstream way of doing that thing has emerged, and you honestly don’t want to keep doing that thing in your incompatible, non-standard, in-house developed way. Simply by creating less inconsistency in the abstract symbolism used to leverage that feature, you make everyone’s lives easier. Most importantly, it makes yourself more efficient, more capable of moving forward faster to the actual new features that people want, and ultimately a better participant in the modern economy, serving more people with less work.

Read on →

Smartphones not made in China

2018-12-14

Categories: misc  
Tags: misc  

Are there are smartphones not made in China? In short, the options are few and far between, but yes, there are some smartphones not made in China. Arguably, most of the smartphones not made in China are made elsewhere “by accident,” but there is one company that is fairly committed to keeping manufacturing in Taiwan: HTC.

This is an older article from 2012.

20181214/https://www.cnet.com/news/are-any-smartphones-not-made-in-china/

This is an article that is up-to-date with the times of 2018.

20181214/https://www.zdnet.com/pictures/10-best-smartphones-not-made-in-china/

So, what does the Wikipedia article have to say on HTC? Alas, HTC is kind of pulling out of the smartphones business. After having collaborated on the development of the Pixel smartphone, they sold a bunch of their smartphone talent and IP to Google in 2017. Ah, but from the previous article, I saw some of the Google Pixel smartphones were made in Taiwan, although not marketed as such. Well, there you go. That’s where to go to look for the “modern HTC” smartphones.

20181214/https://en.wikipedia.org/wiki/HTC

Okay, so I was thinking about “house logs for dummies,” and one thing became generally evident. For virtually every project that you do, the step one is identical: survey. Building a new home? Survey the land before laying the foundaton. Moving into a prebuilt home? Survey the prebuilt structure that is lacking the blueprints. Trying to get data on a home in operation? Survey the home so you can determine how you need to instrument the sensor network. Detecting inaccurate data caused by missing data in your sensor results? Grow a bigger sensor network, but of course sensor network growth must be guided by… yep, you guessed it, survey data.

Whether the project be to build something out or to measure something in operation, the universal first step is to survey. Unfortunately, I don’t think I can say there is a universal second step. If you want to run things in a rich data-driven manner, the second step would be to build out a sensor network. But, if you want to do things bare-bones, you could just as well forgoe surveying and data collection until you need to perform a major undertaking. Yes, this does mean that if anything goes even slightly wrong, you risk forgoing the ability to catch the problem early, rendering what might be a small fix into a major repair.

So, one idea that came to me for implementing on this blog is the idea of article development levels. Indeed, I had seen this before with documentation on Blender plugins. Also, looking at my blog side-by-side with the Mr. Money Mustache blog, looking at the differences in writing styles. My blog is kind of a blend between traditional blogging and Twitter-style writing.

So, here is my grading levels for blog development status.

  • Level 1, Twitter-style short messages. “Blogging for dummies.” The main advantage over vanilla Twitter is the inclusion of categories/tags across all posts.

  • Level 2, short blog article. A few paragraphs are included for conciseness, but the article is otherwise still a fragment of thought that only makes sense in the context of the larger body of articles within the same category/tag. The writing style may not read and flow as nicely as what you’d normally expect from a blog.

  • Level 3, complete blog article. The length is long enough to give background information and context in the article on its own, the writing style flows well, and the article overall represents a more complex and complete thought.

Wow, and I just realized that I’ve effectively used the same leveling system that I used in “house logs for dummies” right in this blog development status classification: three levels, the first level is for dummies, the second level is a bit more advanced, and the third level is the all-inclusive advanced catch-all for experts.

How do I implement this in my blog? Well, I think by now, I am stretching the Jekyll blogging system to its limits. For this, I would essentially need support for the concept of variables assigned to articles that have numeric values. Yes, I could emulate it with categories and tags, but then implementing the next level of dynamic filtering based off of parameter selections would be quite tough.

Now that I’m getting my blog writing underway, I realized that I’ve got to have a pain-free way to set up the preamble for my blog posts. So, here I have it. A simple Emacs interactive function to fill in the parts of the preamble that can be automatically generated to get you up and running on your blog writing fast!

(defun blog-new-post (tags)
  "Generate the preamble for a new blog post."
  (interactive "MTags: ")
  (setq cur-date (decode-time))
  (setq pick-date (cdr (cdr (cdr (reverse (cdr cur-date))))))
  (setq tz-sec (nth 8 cur-date))
  (setq tz-min (% (/ tz-sec 60) 60))
  (setq tz-hr (/ tz-sec 3600))
  (setq tz-num (+ (* tz-hr 100) tz-min))
  (setq fmt-date (append pick-date (list tz-num)))
  (insert "---\n"
          "codename: \n"
          "layout: post\n"
          "title: \n"
          "date: "
          (apply 'format "%d-%02d-%02d %02d:%02d %+05d\n" fmt-date)
          "author: quorten\n"
          "categories: [" tags "]\n"
          "tags: [" tags "]\n"
          "---\n"
          "\n"))

My experience using this code in practice for blog article authoring? Wow, it sure makes the process super-slick!

Again, I reiterate, because this is important! Many times I wonder if there is a single software platform that you can place your bets in of it being compatible with your higher level software and data for years to come. Indeed, Unix-like systems are about as close as you can get to this ideal, as they have both been around for a very long time and have been very resistent to compatibility breaking changes, even those that would add an important feature. Linux, though being a little less conservative, is still very strong in its Unix roots of resistance to change.

But, the bigger lesson to be learned is this. Time and time again, throughout the history of computer software, we observe that there is some old and well-established software project that seems to be pretty stable, but then an up and coming forerunner comes totally out of the blue. They start out with a small development team and a very weak technical code base, but they have a technical advantage simply through their development methodology that allows them to grow much faster than the old incumbent established players ever have. Pretty soon, this higher growth rate causes the new project to completely eclipse the old project in a fraction of time so small as to be unimaginable to the original old project developers. Current users of the old project switch over to the compelling new project, despite the obstacles, difficulties, and transition costs. The developers of the old project try to adapt to catch the wind of the pace of the new project, but no matter what they try to do, they can’t seem to keep up. Finally, the developers of the old project just quit and tell anyone in their existing user base to switch to the new project that has since replaced them.

Read on →

I was reading about the Cinnamon desktop environment recently, thinking more about the GNOME 3 controversy, and that reminded me of something. Despite the large number of computing platforms ever created, there are only very few that have really moved most of us as software developers. So few, that they can be counted on the fingers of one hand. So, let’s rehash what those are.

  • Early PC microcomputers, early 1980s. These are of the likes of the Apple II, Commodore 64, IBM PC, and so on. The key feature of these systems was to introduce BASIC and assembly language programming to people far and wide, essentially spawning a new generation of software developers on a much more massive scale never seen before. Most early PC microcomputers shared no software compatibility in common.

  • The Macintosh computer, late 1980s. Being the earliest, cheapest, and most mass marketed computer to sport a graphical user interface, it was instrumental in introducing the concept of graphical user interfaces early on to many programmers far and wide.

    The printing interface introduced with the Macintosh computer was a major landmark. Using a graphical user interface dialog to prepare for printing, driver support for multiple different printer backends, and access to network-attached printers set the standard of computer printing forever.

    In terms of software compatibility, there generally was still no such thing at this time. Similar systems for other mass market computer hardware that have been introduced later, such as Windows and OS/2, were mutually incompatible with each other, though Windows had many technical features that were came directly from the Macintosh due to a short-term partnership.

Read on →