Welcome!

Posted on by srcCrafter

After many delays, caused by either life issues and events pulling me away from this project or because I needed to learn a bit to get this project going, welcome to my new blog!

So… what is this blog all about? Well, the tagline is pretty descriptive. The remainder of this article attempts to expand on that, describe the problem, and outline a solution.

The Problem: Old Dog, New Tricks

IT Codger with an old (circa 1983) BS/CS who originally did “scientific programming” (as opposed to “business programming”) but then wandered away from the “one true way” (programming/coding) to do other IT-related tasks. Now retired, this codger wants to get back into programming/coding which, these days, means “website and web app development” (if one wants to be in the sweet spot of the technology).

As an aside, when I say that today “development” means “web and web app development,” I think it’s because the world has migrated away from installing software locally (the .exe files on a computer) to running software that exists on someone else’s computer (really a server somewhere). There are, I think, multiple reasons for this:

  • We don’t trust software with which we are not familiar.
  • Why take up local disk space with something we only need occasionally.
  • The “remote” software is (assumed to be) maintained and updated by someone else.
  • If we have multiple devices (desktop PC, laptop, tablet, phone), we might not be able to “install” an .exe on all of them, but we most likely will be able to access a website or web app from them all.

So, how does this old dog learn the new tricks?

Of course, it’s not just about the languages and new technologies. There has been a lot of progress on best practices in the last 30 or so years, and that’s an important aspect of becoming a modern developer.

Security has changed over the decades as well. Gone are the days when a username and password were sufficient to secure anything.

The Objective: Personal Growth and (maybe) Supplemental Income

I do not want a full-time job (and really hope I never need one again).

I do want to keep mentally active, and as much up to date on IT as I can.

I absolutely want to write code.

I probably want to pursue some personal projects that interest me.

I might want to do some occasional freelance work.

The Solution: srcCraft.net (the site you are reading)

Document the journey of an aging programmer into the new era of Web Development. Or something like that.

Survey what’s currently available – and what might be coming soon.

Determine what to focus on and then (attempt to) become an expert in that: HTML, CSS, Javascript (both client-side and Node.js), Ionic, VUE.js, Python, Flask, MySql, and SQLite should make for a challenging journey.

Start with the basics. Be consistent. Write some code every day. Stay focused.

The Technology: What’s here for the long term?

PHP – the original server-side web language

It’s probably not going away any time soon, because it’s the language in which WordPress is written (and WordPress is used for something like 35% of all websites worldwide).

Javascript – the language of the interactive web.

Good info at https://www.w3schools.com/jsref/default.asp.

Node.js – Javascript on the server.

The official site at https://nodejs.org/en is a useful place to start.

Javascript Frameworks – VUE -vs- Angular -vs- React?

Good overview at https://www.youtube.com/watch?v=lYWYWyX04JI

  • Angular is from Google, is more platform than framework, big (can be overwhelming).
  • React is from Facebook, is minimalistic, rather a library than a framework, no built-in routing.
  • VUE is a standalone open-source project, framework focused on code, somewhere between Angular and React with respect to complexity and completeness.

And the winning, Pie-in-the-Sky combination (for now, anyway) is Vue (a progressive Javascript framework,  https://v3.vuejs.org) and Ionic (a UI toolkit that can work with Vue, https://ionic.io).

However, the winning, pragmatic combination is WordPress using Understrap.

Python and Flask – an alternate way to develop web apps.

Official Python page at https://www.python.org/, and https://pypi.org/project/Flask/ for Flask.

Infrastructure – the servers where everything runs.

Digital Ocean (https://www.digitalocean.com/) is relatively inexpensive but also bare bones. Lots of article on their site to help, but everything is basically up to the user.

Microsoft Azure (https://azure.microsoft.com/en-us/) is more expensive (can be a lot more expensive) but has all the “bells and whistles.” Also, there is a lot of support from both Microsoft and from third parties – most of which must be paid for.

The Process: My Approach to Getting This Done

Step 1: Define the problem and conjure a solution.

See above for “The Problem” and “The Solution.” Of course, that’s an abbreviated version of “search the Internet for articles relating to getting up to speed with new technologies and scouring the results for those relevant to solo development.” Solo development because, let’s face it, who’s going to hire a retired old dog like me to be on their dev team?

Step 2: Come up with a project/domain name that isn’t already registered.

The “come up with a name” part is easy. It’s the “domain name that isn’t already registered” that’s the problem. It almost seems like there are some folks (bots?) that try to register every conceivable combination and variation of clever (and not-so-clever) English language names and words in the hopes of later selling the name for big bucks. For example, one of the domain names I thought of first – and really wanted – was sourceror.net. You guessed it – it was already registered. Entering sourceror.net in the URL bar of a browser reveals a non-SSL parking page indicating that the name is registered through namecheap.com and consists solely of questionable-looking links with names like “Car Insurance,” “Credit Cards,” “Life Insurance,”, “Dentists,” and even “Comcast,” though the link named Comcast did not appear to lead to the actual comcast.com site.

“Sourcecraft.net” was also already taken, so I finally settled on “srcCraft.net.” I suspect most developers today – even the ancient, out-of-touch ones like me – are going to recognize “src.” And the “craft” part alludes to a combination of science, art, intuition, and flair that a good developer would need to possess.

Step 3: Outline a plan.

Note: the plan is dynamic and is constantly evolving. Change is the only constant…

Re-education: learn the languages, frameworks, tools, and approaches. This will, at first anyway, be done via courses on sites such as FreeCodeCamp, uDemy, and Codecademy; tutorials on the language and framework sites; references; and examples on W3Schools.com, and various YouTube videos.

Reading: books about programming and programmers, technologies, and methodologies.

Branding: if one of the objectives is to document the journey, then some branding is useful. So far branding has encompassed the following:

  • Registered the domain name srcCraft.net.
  • Created a closed (that is, invitation only, for now at least) Facebook page for srcCraft.
  • Created a Twitter account name of @srcCraft.
  • Changed LinkedIn and FreeCodeCamp usernames to srcCraft.
  • Selected a few photo assets from Unsplash.com.
  • Created a logo: “./srcCraft” 
  • Created a “Coming Soon” page with a date and countdown.
  • “Coming Soon” page is live.

Step 4: Determine a timeline.

I originally hoped to have this site up and running in April of 2021. That didn’t happen. The target date changed about 5 times, finally ending up at January 18, 2022. I beat that date by a few days. The delays were caused by two primary problem domains: (1) life events and issues pulled my away from working on this project, often for several days to a couple of weeks at a time, and (2) I followed several rabbit trails of ideas that ended in dead ends. The life events and issues were generally unavoidable, and many of them advanced goals I have for my real life. The rabbit trails, while frustrating at the time, resulted in learning (which is never a bad thing) and a better process and product.

Step 5: Work the plan and document, document, document…

I’ve spent time off-and-on over the past year and a half on this site. For (most of) the rabbit trails mentioned above I made some notes that will become future articles here.

The Plan

Initially, work toward going live with the ./srcCraft site at noon Eastern Standard Time on April 20, 2021:

  • Create, or collect and modify, visual assets to use on the site.
  • Determine the overall layout, structure, and menu(s) for the site.
  • Select and customize a WordPress theme for the site.
  • Finally, write (or borrow and modify) a Privacy Policy and Terms of Use for the site.

In parallel with the above, learn to efficiently and effectively use the available tools (VS Code, IntelliJ IDEA, PyCharm, Git (and GitHub), and, lest we forget, Stack Overflow).

The Resources

  • uDemy (pay-per-course (with heavy discounts periodically offered))
  • FreeCodeCamp (free)
  • W3Schools (free)
  • YouTube

Web resources found via Bing.com search.

This basically sums it up:

Various not-so-helpful links:

From Stack Exchange (these were the most useful resources):

An interesting looking paper from long ago:

An interesting take on an approach to debugging:

Somewhat complex/overkill; maybe useful later:

Finally, a pretty negative/defeatist view of the solo developer (not particularly helpful or motivational):

Some excerpts from the more useful Stack Exchange threads

  • Many agile techniques work great solo:
    • User interviews and stories: If you don’t know what your users want, why would your software be useful?
    • A simple spec: Or even just be a mission statement. “Let people broadcast short messages to their subscriber lists.” “Use in-degree to sort internet search results.” “Let people collaboratively answer programming questions.” Whatever.
    • A strictly-ordered todo list: Helpful to keep you from drowning in thoughts.
    • Tangents log: A good to-do list has a “to-don’t” component, so you don’t obsess over things you aren’t going to do (yet).
    • YAGNI: Stay on target. This is very important when working by yourself, because no one is there to tell you “No! Don’t reinvent dynamic typing in Java! Get back to the project.” To-don’t lists help with this.
    • Test-driven development: Writing tests forces you to think about the end result, rather than getting bogged down in implementation details. You’ll get bogged down enough anyway; no need to make it worse.
    • Frequent releases: Make yourself stick to deadlines. “We’ll have a feature-complete version that includes user stories 1-4 by Friday. It won’t connect to the network or save data to disk, but XYZ…”
    • User testing: Have your buddies look at what you’re making on a decently frequent schedule — maybe once a month, maybe every week, depending on how many friends you have and how much beer/pizza you want to feed them. Pay very close attention to what they say and do and think when using the software.
  • Other things that only seem like they make sense in big projects can help a lot:
    • Source control: Install git. It’s bone simple. Use it. Don’t obsess over it.
    • Off-site backups: Y’know. In case of house fires or floods.
    • A blog: But you’re only allowed to write there when a release comes out. 😉 Also helps you build an audience for your product before it even ships.
  • If you are working solo. Here is some advice:
    • Do as little low-level work as possible. Use as much library and tools as you possibly can including things you think you can easily code (don’t do it, just use the library).
    • Take the top-down approach. Only code things that you really need.
    • When you see a problem in abstract term, search on google and use research papers from academic community which has been proved already. You only need to code their algorithm.
    • Design your system so that you can freely change things as much as possible. (including copy and paste some code from here to there). The purpose is to save you time when you realize you made a mistake. Try to minimize the amount of work you have to throw away when you make a mistake. A piece of code that has to be thrown away (instead of copy-paste from here and there) is the equivalence of time you lost writing that code.
    • Have lot of automated tests so you can regularly do regression tests each time you make a change
    • Separate the responsibilities of your design (i.e. reduce coupling). Make things as modular as possible
    • Use a debugger to debug and use binary search to find defect.
    • Constantly refactor your code to reduce (explicit) coupling and public methods exposure (implicit coupling).