What the Flutter?

Rules were meant to be broken and I’m running headlong into this new rabbit hole for no real reason other than the fact that I have the attention span of drunken roadkill. This rabbit hole is called Flutter, which seems aptly named after my brain’s inability to stay on point, but rather to flutter from one thing to the next. Per Flutter’s web page, “Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase.“ I can’t honestly say how far along I will venture on this endeavor, but the ability to create my own mobile applications has always intrigued me, but has also always been outside my realm of knowledge. I have had rudimentary investigations into XCode, but have never really spent any time on it and have not even acquire my iOS developer access for $99 a year. I know, I’m a cheapskate. This is an opportunity to see if my braincells have hope of grasping these concepts, to see if my discipline will allow me to persist in my investigation long enough to reap the benefits and finally to be able to deploy my application to many endpoints making the effort all worthwhile.

Am I On The Right Path?

Getting started with this requires downloading the zip file from Flutter’s website and unpacking where I want, then setting my PATH to know where it is. As it is literally EVERY TIME I HAVE TO SET MY PATH, I screw it all up… this time was no different. Long story short, I first didn’t close the quotes in my .zshrc file, then I simply didn’t put in the right path to my flutter/bin. An easy fix really, but this stuff always takes me friggin forever.

Once that was squared away, I ran flutter doctor in the Terminal, which let me know that Google will be spying on me if I choose to use this application (fucking bastards). I didn’t see any ability to opt out of this either. After that was complete, I see a few issues. First, I do not have Android SDK installed. Obviously, it would need this for me to deploy Android applications, but for now, I’m going to stick to iOS, until I have an app I want deployed for multiple platforms. Same thing for Android Studio. For the XCode section, it says I’m missing something called CocoaPods. CocoaPods is used to retrieve the iOS and macOS platform side’s plugin code that responds to your plugin usage on the Dart side. Without CocoaPods, plugins will not work on iOS or macOS. I’m going to go ahead and remedy this, and see about getting CocoaPods installed.

CocoaPods is built with Ruby, so I used RubyGem to install, which calls for installation using sudo. I tend to balk at that process, so I used the sudo-less method, which seemed safer, but required me to make some mods to my .zshrc file to get the PATH squared away… I bet you can imagine how that all worked out. After wasting some time with that, I gave up and went back to the originally recommended method using sudo and got it installed w/o any apparent issue right away. I went back and ran flutter doctor again, and CocoaPods is no longer being flagged.

OK, so I lied. I’m installing Android Studio and then the Android SDK. Don’t ask me why. One thing though… I don’t understand Homebrew. I’ve used it a few times now and I never know where is puts anything. Same just happended here. I decided to instal just the Android SDK and used Homebrew. Of course, Flutter couldn;t find it and I noticed then that Flutter provided different instructions on how to do all this. I had to wonder to myself why I always seem to gravitate toward the hard way first in everything. So I hunted down the Homebrew installation of the Android SDK and am now installing Android Studio. From within Android Studio, I will pull in the SDK and see if Flutter approves.

This actually took me awhile. There are some issues with the Android licenses that took some additional Googling and installations, but I finally got it worked out. Flutter says, “No issues found!”

Test Drive, Vroom Vroom!

After all that B.S. with Android Studio, I’m still going to take my leap into the Flutter foray using Visual Studio Code. On first glance, Android Studio looks exactly like XCode, which is pretty much over my head. I’m hoping to gain some initial familiarity using VS Code, so that I don’t bail out on this right away.

Jumping in to VS Code, I needed to pull up the Command Pallette (cmd + shift + p) and enter flutter and then select Flutter: New Application Project, but of course, nothing shows up in the command pallette for Flutter. The Flutter Dart Code Plug-in was supposed to install automatically when I installed Flutter on my machine… not sure what happened there, but I just searched Flutter in the VS COde plug-ins and installed it myself. I did get a VS Code message asking me how I wanted to configure my Dart Code settings, but since I don’t know shit about this, I went with the recommended Dart Code settings. I was then able to create a basic project instance using Flutter: New Application Project in the Command Palette, which not only created the file structure, but included a really basic button click-counter application. How do i know what it was? Well, I hit the Play button in the little control panel that I assume is part of the Dart plug-in I just installed and it ran the application in Chrome as a web app. Pretty neat-o! But wait, it gets better. There’s a device selector in the status bar at the bottom right of VS Code. I clicked it and it opened my Command Palette, which listed the devices I had available. I changed it to iPhone SE and then clicked the play button again… XCode launched an iPhone simulator with the same button counter app… FROM THE SAME CODE! I then switched the device in VS Code again, this time to a Pixel 3. When I ran the ssame code this time, Android Studio launched the Pixel 3 emulator running the button counter app. I must say, I’m impressed.

Looking back at my default project in VS Code, I see a file called main.dart. First time I’ve seen Dart code and it looks a lot like OOP JavaScript… I might actually be able to figure this stuff out! All in all, I’m pretty excited about this. Admittedly, this rabbit hole is turning into a pretty big cave, but the stalactites are so pretty… I might have to stay for awhile. More to come for sure!

A Few More Minor Details

After a bunch of screwing around in my hosting account and eventually a call to the provider, I finally was able to get this blog deployed! It’s sort of bewildering that sometimes even the simplest tasks, in this case FTP, can become burdonsome and time consuming. I never really figured out why I had all the issues… I ended up just creating a brand new FTP user account and using that instead.

Deploy to Web Server (continued)

Once I finally got the FTP thing squared away, I went back to VS Code to look at deploying the site using my liximomo SFTP plugin there. As I am really new to what I consider to be these new application file structures that are being generated by the tools I’m installing via NPM, it didn’t really occur to me that I’d have both source files and my generated public files that will go on the web server. Right now, my VS Code workspace is setup to via all my files initiated by Hexo, so using SFTP from here will not deploy to the correct file structure on my web server, and in the interest of what is becoming my mantra: avoiding rabbit holes, I decided to forgo the VS Code SFTP method, for now, and just push what I need to my server using a seperate tool–currently CyberDuck.

Current Process

I’m writing this out here to not only have a place to look this up for reference (probably tommorrow), but to possibly help push this into my brain a little better… maybe even remember it tomorrow ;)

  1. Navigate to the amen2that hexo directoy via the Terminal and type:

     $ hexo new "Title For My Next Post"

  2. This will create a Markdown file in my source/_posts directoy, which I can access using VS Code and write to my heart’s content.

  3. When I want to look at what I’m writing, I can run the blog in my localhost by running the following command:

     $ hexo server

  4. Once I am happy with my post and am ready to deploy it, I can do that by running generate command, which will compile my source files and generate my site in the /public/ directory. once I’ve don that, I’ll use clean, as it will clean the cache file (db.json) and deploy command, which will also push the public files toamen2that.github.io

     $ hexo generate
 $ hexo clean
 $ hexo deploy

  5. Lastly, I will want to push my public files located in my working hexo directory, ‘./amen2that/public/*‘ to my web server using whatever SFTP application I want… currently CyberDuck.

  • If I’m looking to write posts as drafts, which is referred to as a different layout in Hexo, I would use the following:

     $ hexo new draft "Title For My Draft Post"

  • If I’m looking to review my draft content locally, I can add the –draft flag

      $ hexo server --draft

  • Once my draft content is ready to publish, I can run the following to get it added to the _posts directory

      $ hexo publish draft "Title For My Draft Post"

Don’t Be an RSS Hole

Now I can’t honestly say I’ve ever done much with RSS, either generating or consuming, but since this blog theme has a link to RSS that is currtly not doing anything, I’m seeing an opportunity to learn something new. It’s a rabbit hole, yes, but I’m going to keep this initial exploration rather limited. I want to simply install the hexo-generator-feed plugin in order to generate this XML content. I will worry about what to do with it later, but I just couldn’t live with a link to nowhere in the short term.

Well, I’m back from creating my RSS2and Atom feeds, both generated automatically after installing that plug-in, adding a few lines to my config file, then starting up the hexo server. Piece of cake! So now that I’m out of that hole, what’s next?

Deploy This?

So I’m still just getting warmed up with some of these new tools and am all thumbs. I recognize the criticality of getting familiarized with the blogging process and making sure that my content is being version controlled and published appropriately; however, I’m also trying to avoid getting wrested away from my defined focus with the many tangential rabbit holes littering my way on this journey.

Github Deployments

My first aim was to get the Hexo deployment process configured to post directly to my Github account. In planning for this, I became aware of something called Github Pages, which is probably not new, I’ve just become hopelessly out of touch with what’s going on in the modern development world. This is a free space for me to post a web page or site using my own Github account. Since I’ve typically viewed Github as a storage repository for verion control, I also figured I would want to deploy my Hexo source files there, while I would deploy my generated files in the Github Pages location. Also, since I have my own web hosting with a private domain name, I wanted to configure this process to deploy there, as well. From a quick review of the docs, it seems that I can do exactly what I want… piece of cake!

Well, in order to deploy both my generated files and my source files to Github Pages and a supporting repo, I need to use Github Actions to make this work. I took a stab at the instructions found here to get this working, but had issue right out of the gate. As I tried to read more about Github Actions, i started feeling like I was slipping into my first rabbit hole and decided, rather quickly, that maybe this is not a necessary route, for now.

Hexo Deployment Plug-ins

There is also an option for One-Command Deployments for Hexo that has different plug-ins available to serve your needs. My first need is to get my stuff pushed to Github and for that, I can use a plug-in called hexo-deployer-git. The only caveat with going this route is that it will only deploy my generated files to my Github Pages location, but not allow me to push the source to a standard repo. Although this is not my perfect world, I’m going to go ahead with this and just back up my source files manually using the standard git processes, which I need practice with anyway. I went ahead with the steps outlined and installed this plug-in, updated my _config.yml file with my Github details, then ran hexo clean && hexo deploy to generate my site and push to my Github Page. After verifying with between Github and VS Code that this was what I wanted, my Hex Blog is live on amen2that.github.io/!

Now that I’ve gotten my content on my Github page, I think about how I didn’t even know what that was until this week and so clearly, it isn’t what I set out to do. What I really want is to get this blog posted on my private domain. Fortunately, there’s a plug-in for that too called hexo-deployer-sftp. This, too, seems pretty straight forward, but I notice a warning on it’s github repo just warning you that it will delete everything off your server to match what you are deploying, which isn’t what i want to do. I figure I could test this and figure out how to make it work, but obviously my first step will be to back up what’s out there, thengo to work with tests… these fucking rabbits man!

I’m going to back up a second here… why do i need to deploy using Hexo? I can use VS Code to SFTP whatever files I want to my site really, really easily, using a process I’m already familiar with… SFTP!!! I mean… what the hell am I doing here. So the new steps are going to be to simply generate my pages using hexo generate, then just push them the old fashioned way from VS Code using SFTP. I mean… WTAF.

Well Here We Are!

It looks like I’ve finally gotten around to getting my blog launched. It seems that I’ve been this far before, but it’s really much harder to maintain and develop a blog vs. just getting it started. Hopefully, this time will be a charm.

What’s The Plan?

My plan will be to focus much more on documenting the things I’m learning to help me organize and better remember all these new things I discover and learn, and if I don’t rememeber it, which we know I won’t, I’ll have something here i can refer back to and jog my memory.

I know that there are many things on my list to learn, so my entries my be a bit disjointed in the topics that are being logged, at least initially, though my focus will be around front-end development, starting with HTML, CSS & JavaScript. It seems like I’ve been doing this stuff long enough that I would need to start there, but fundamentals are pretty critical and I know that there are some serious gaps in my knowledge.

Stick To The Plan!

But even at this early onset of my new endeavor, I’m going to go off track and spend a little time on something else called Markdown, which is a document formatting mark-up of some kind that I’ve only very recently even heard of. I’ll be looking to this handy guide on Markdown basic syntax for starters. I’ll also be learning a bit about this blogging tool, Hexo, which I just discovered today. I’m going with it due to its apparent simplicity and apparent hackability… hopefully my instinct is true on this choice! Lastly, I will (once again) be delving into GitHub since Hexo is integrated into it by default and, frankly, I just really, really need to get my head out of my ass and learn this one.

OK, that’s all for now. Cheers!