< prev 14 Jan 2018 to 20 Jan 2015 next >

Posts tagged 'website'

  • Proof of concept

    So. I have a local version of my rails re-write of this middleman blog working. For various reasons I decided that going for full control made the most sense1, and thus I ended up with something that's mostly okay. It's clear that certain doors are open now that weren't before, but it's taken a lot of effort to get here.

    One of the habits I wanted to train myself in is in learning to accept external code more readily. I think I'm mostly won on that front, but it's still not perfect. The time it takes to learn an API is not always trivial, and it's not clear when my own assumptions differ from those of the authors' whether I'm correct, or they are. Case in point: I wanted some way to slugify categories and tags, and so went looking for ruby libraries that enable that, and found friendly_id. It's pretty capable, but one thing I wanted to do was first_or_create_by_slug. After looking through the docs, then the code, for a solution that would make this possible, I started to open a new issue asking for a way to do this. I quickly realized that my request would be meaningless, and I was better off putting together a hack that addressed my own needs, rather than asking for a general purpose solution that wouldn't be a positive addition to the gem.

    Would I have realized this if I had elected to write my own code, or would I have made some hack that got me halfway only for me to realize that it's completely infeasible?

    I am certain that using someone's CSS library (in this case, Zurb's Foundation) was a step forward. I hate worrying about browser compatibility, and at the end of the day I simply want a vocabulary that allows me to express visual ideas in a flexible way. CSS is a nightmare to figure out from source; thus, front-end frameworks offer advantages through documentation, examples, and actually being tested by people who care.

    Back to the main thread: I've sort of paused out. This is being written via a web page on my local computer, and… I added two-way data pathways (import/export) from rails so that I can import test data (== my old blog posts) and compose new posts that can then be slurped up by middleman. It's not ideal—it's not the hosted solution I alluded to in an earlier post—but it's quite similar to the "admin app for composing static pages" half-solution I sketched out. The interface, and codebase, are both things I feel comfortable working on, and some of the ancillary effects I was hoping to see have panned out.

    That is to say, I'm seeing how I can better (solo) handle problems I haven't seen before (like, finding and using Foundation in the first place), and getting better at judging what is and is not worth my time, even when I don't always close the loop on this knowledge. And adding weird features for personal use—like a button to output a post to markdown—doesn't feel as off-putting to me now as it might have in the past.

    On the other hand, I did spend too long getting this site's CSS re-written so I could get the form classes for free, so it might be that the biggest gain I've gotten is clarity. I can see clearly now in all the ways I'm doing things that aren't in my best interests.

    But it's all so pretttttty, and flexible!

    The wall, now, is that getting the proof-of-concept code/configuration for external hosting and e.g. blue/green is … not a priority anymore? I can output whenever I want, and I've found stopgap ways to track the things I want to say, and while they're not all going up on the web yet, I can see a path that will make that happen in due time.

    1. Namely, I want to extend the blog model in ways that aren't easily enabled by most blog platforms/static site generators, and the convolutions I could see happening in the near future were getting extreme. ↩

    12:11 AM - 14 Jan 2018 in journal
  • Moving costs

    One victory and a couple setbacks.

    I've been thinking about moving to AWS for some time, which caused me to change my billing on Dreamhost to month-to-month. (Given that I did this probably two years ago, I'm not sure the economics have really worked out.)

    Per my previous journal entry, I am considering moving to a static frontend/app backend. It's just and proper that I establish my motivations and desired outcomes for this configuration:

    • The ostensible purpose of all this is to have my computing resources meet some standard for stability, reliability, responsiveness and usefulness.
    • Stability and reliability are a function of delivering on DevOps skills, i.e. setting up automation and so forth.
    • Responsiveness means no free heroku dynos, and no Wordpress slowness.
    • Usefulness means again, no Wordpress slowness, and providing a lot of the features I sketched out in yesterday's brainstorming. Basically, the personal goal here is to have all this heterogeneous content available and browsable in a sensible way.

    Now, the professional goals here are a bit orthogonal. This configuration should act as proof-of-concept for a number of infrastructure skills that I intend to profit from through work. So the idea of hacking together something that just gets the job done satisfies personal goals but doesn't satisfy the larger professional goals.

    For the time being, journaling in sublime and pushing via scp will have to suffice, then.

    Meanwhile, as much as I like the terms of DreamHost's happy hosting, there are some downsides. Although it looks like you can get away with installing a ~recent version of ruby and running whatever rails version you want, their knowledge base makes clear that they'd prefer you don't on shared hosting. I can move up to a VPS (which would allow me to gain some of the account controls I wanted—more on this later), at the cost of $15/month.

    Here, I come to a fork in the road. A lot of the employers I've talked to are ~early stage enough that they get by running on heroku. While I'll admit heroku is a bit of a mystery to me (beyond their relatively painless ruby deploy process) I'm not sure that's the basket I want to put my eggs in.

    Meanwhile, there are a couple other options. I could go with AWS because of its practical applications, or for instance DigitalOcean or Google Compute. I think I'll end up on AWS but it's probably worth considering all the alternatives.

    If I go with AWS, the temptation is to proof-of-concept setting up overkill architecture to gain experience with as many technologies as I can. That's kind of the point, but I can foresee there being a lot of barriers to success there if I'm not careful. (Also, I don't much like Amazon, the company.)

    Ultimately it doesn't much matter, except inasmuch as I don't rely on the crutches of one-click installs and GUIs to configure everything.

    Finally, there's a lot of variability in terms of pricing, and I should really look into that a bit more before I commit to a particular infrastructure.

    All this said, I have some concrete goals in mind. First, keep this site (ed: static site hosted with DreamHost) resolving as long as possible.

    Second, set up an acceptable dev environment, and begin automating everything. Figure out setups/teardowns and immutable infrastructure, backups, etc. before committing significant data to it. This approach has the advantage of saving costs while the system isn't running fully.

    Third, establish migration tools to move the data from middleman to the new platform.

    Fourth, test everything and then close down shop and re-route DNS to the new server.

    I alluded to a victory in the first paragraph. Well, it turns out that for a site like this one, rails offers pretty turn-key page caching that gets served directly from nginx or apache. Score.

    4:27 PM - 21 Dec 2017 in journal
  • Website configuration
    • Easy deployment
    • Backups, in transferable format, of post content
    • Total ownership of content
    • Post by email
    • Post by web
    • Formatting for short posts, versus long form writing
    • Easy configuration/additions without scp (e.g. git push/commit hooks)
    • Low server overhead—it's a damned static site 99% of the time; it shouldn't require an m4.large
    • Article permalinks regardless of underlying categorization/content changes
    • Presentation of heterogeneous data
    • A way to share more than just text (e.g. images)
    • Maintain pagination without incurring excessive backend load
    • Portfolio elements—running/presenting arbitrary code, separate from blog content/formatting (e.g. cssris)
    • Extensibility
    • Easy import/export
    3:04 PM - 20 Dec 2017 in brainstorming
  • Short posts

    I've achieved the goal of having something I control, but there's a weakness here: I haven't found an easy workflow that lets me get short thoughts out quickly and painlessly. Yesterday I wanted to write about a half dozen topics that didn't merit a full journal entry, but didn't have an easy way to do it. I ended up just opening a new note on my phone and brain dumping, which isn't the worst thing ever.

    I'm trying to avoid using a database, but a lot of the stuff I want to do is most easily solved with access to a database. A forum of this scale doesn't merit a backend, or at least strongly benefits from being statically generated. On my feature list, however, are a lot of things that become easier if I'm running a real server, or at least building the site off something that has a database available.

    … Hmm, now that I think of it, that's not a bad solution. The ideal admin tooling suggests the need for a first class backend, but I can easily use that to generate a static site that gets the benefits of both worlds.

    Spitballing here, there are a couple decent ways to get a simple, high speed personal website running in the hosting environment I have available.

    • Run a tiny app for one user that has reasonable login protections. When I hit a button, dump some form of the content into a format that a static site generator understands, and have that generator deploy the content to my preferred host (could be S3, could be similar to the current configuration).
    • Wire up a tiny blog app that caches aggressively when not signed in. I've seen some of this magic in a previous life; the nginx config used would serve assets directly from nginx instead of routing through rails, boosting app speed. If there's a clean way to have rails do that automatically, I might go that route.
    • Use normal app-level caching and hope for the best. I don't much like this one because I would have to do a lot of testing ahead of time to ensure that I could serve hundreds or thousands of requests for the same page without hitting server bottlenecks.

    Taking a step in any of these directions will change the calculus I've been using so far. Notably, it's been easy (or, relatively easy) to bulk import/edit preexisting posts to work with this tech stack, but having a database at a distance will make it harder. Since I should be doing more original writing and less migrations as time goes on, the balance of burden will shift.

    Looking back at my decisions up to this point, the following facts are true:

    • I'm happy that I've kept data, configuration, and code separate so far; it will make any migration to a different platform easy. Many existing frameworks for producing static sites encourage too much commingling of these things.
    • The mere existence of this blog has been a great boon, in the sense that I'm writing at all.
    • The current form of this site is essentially an MVP: I've got posts on a screen that can be viewed on the internet. In that sense, it's a win so far. It looks like any path forward will demand more backend work and server orchestration, which was half the purpose of this exercise in the first place. I can't say, then, that I'm upset with this state of affairs.

    I can't overstate how much having this bootstrapped site up and running has been for my mental well being. I feel lately like I'm overflowing with ideas.

    2:43 PM - 20 Dec 2017 in journal
  • Organizing thoughts and data

    Phase 1: Deleting/archiving presence elsewhere

    A big part of this thrust to centralize … myself, for lack of a better word—is getting all the bits and pieces together in one place.

    There have been a variety of platforms over the years. Some have died—I don't think I stored anything important on orkut—but on those that still exist, you can see the entropy.

    I've been convinced of the value of holding onto your data in formats that will resist the test of time for years. Nevertheless, it's amazing to me how much entropy has struck in places where there has been platform continuity for over ten years. Embedded tags (nominally HTML, but obviously parsed somehow by the internal tooling) and other metadata has bit-rotted until everything is nearly unreadable.

    After some effort, I have archives in local storage of almost everything I've ever posted online, and the old versions are "deleted"1 off those platforms.

    With some exceptions. Facebook is a tough nut to crack; I needed to register as a developer to even begin to download my post graph entries, and after toying with it for a bit I'm not sure that I'm ready to go all the way down that rabbit-hole. It looks like I'd have to run a local server in order to scrape an effective copy of my data from them, since their "archive" tool is god-awful for someone who shared as many links as me.

    Phase 2: Triage

    A lot of the stuff I've written down can go back up in due time. A lot of it should never see the light of day.

    This leads to a question of, what's the point of a blog? I know that a lot of what I write now will seem embarrassing by the standards of future me, but this process seems asymptotic. Meanwhile, angsty blog posts from when I was 15 contain … embarrassing turns of phrase, among other things, that don't shed light on who I am now.

    Broadly speaking, I don't believe in deleting things. On reddit2, if I was blatantly wrong, and someone pointed it out, I'd always leave my posts up as a matter of principle, and to provide context for people who came by after.

    But does that mean I have to put everything back up? I doubt it.

    What's interesting about this place is that (my intent is) it is a place to focus and refine my thoughts. The ideas I've gotten the most mileage out of are the ones I write down in a place I also read. So, some turn of phrase or tiny stub in a page of a notebook I constantly flip through worms its way into memory via spaced repetition, essentially.

    This suggests that the real goal is to find the kernels that reflect deeper truths… and then consolidate them into something wiki-like.

    Further, blog entries outside my journals should be considered transient. This suggests another layer of metadata, for posts that don't hold interest because they've been superseded by something more refined or more correct. Not just for currently outdated posts, but for stuff that's fresh now that'll seem stupid in two or ten years.

    Do I need to own up to everything I've ever said? That way lies madness, surely. But reading and consolidating is probably in the cards, which suggests something wiki-like is on the medium term road map.

    Phase 3: Editing

    For the stuff that's worth posting, editing is necessary. I may end up going through and doing this cleanup on everything, but the first-order changes involve more or less the following:

    • Remove useless metadata (e.g. date_gmt, added by Wordpress)
    • Clean up remaining metadata
    • Change formatting to markdown
    • Resolve obvious typos
    • Add appropriate tags and categories

    The point of this blog, again, is organizing the data, so having effective cross-links is the first part of that. As mentioned before, I'll probably need some sort of "archival" tag, to indicate to readers that what they're reading is historical reference3.

    This is a highly manual task. An automated tool might sound good at first blush, but the data sources are heterogeneous and the sorts of formatting that each demanded differ that re-establishing the correct context in markdown syntax demands I re-read and hand-tweak everything.

    In theory I'm not against this, because I want to re-read and consolidate as many of my old thoughts as I can, but 1) it's a lot of content and 2) it's going to screw up my plan to get permalinks running. I don't think date+slug is an effective permalink schema for content where date might not be the most important aspect of what I'm doing, but without a database there aren't really any unique primary keys to work against. I'll have to chew on this for a while.

    Conclusion

    What's the point of all this effort? Well, I have bits and pieces all over, and it's part of a process to more well-define my identity and make my thinking more coherent.

    Journaling is more of a "in the moment" process, that reflects where I am in the day and time. Organizing, as an umbrella, is about finding a kernel of myself, and building on it logically.

    1. Who knows if these platforms actually delete old content, though. ↩

    2. … speaking of sites I wrote content for but never archived… However, so much of what I wrote on reddit only makes sense in the context of the thread it's in, so maybe it's okay that I don't have that. ↩

    3. And perhaps add an obvious note, and cross-links to newer versions? ↩

    5:15 PM - 12 Dec 2017 in journal
  • And, we're back

    So.

    When I graduated from AppAcademy, I hacked up a stand-in portfolio website using turn-key Wordpress provided by my hosting company and a slightly tweaked version of a theme I kind of liked.

    Well, over time I realized I didn't much like Wordpress. The toolkit seemed robust, but so slow, to the point that I would get frustrated playing with settings. I can sort of tolerate that sort of thing, except for the following:

    1. It's a personal home, not something for work, so comfort and familiarity is supreme.
    2. Comfort, for me, is derived largely from things like responsiveness. If there is every visible lag in typing, I get subtly frustrated and that frustration mounts.
    3. The plugins I most wanted to use were flaky at best, and I was not and am not inclined to learn PHP to get (for instance) an email-to-blog portal working
    4. It was subtly messing up some raw entries when they got written to database, leading to subtle rendering artifacts that were hard to fix due to the slowness mentioned above.
    5. I realized the theme I had landed on was flaky in its own way, and I didn't much want to debug someone else's idea of what a good layout looks like.

    All credit to the authors of WP, and free WP themes, but they're just not for me, not for this.

    So I had been vowing to re-write my blog to something I would enjoy, and fiddled around with a couple things over the years. It never was a priority, so I tinkered back and forth between rails and static site generators, like Jekyll.

    I'm going to elide a huge amount of history and research, but basically I realized a hand-written rails CMS was a total waste of time, and the half-measures—existing rails CMS apps and engines—were inappropriate for my goals. I made a fair shot at using Jekyll, too, but liquid is way too constraining1 for a personal site where I have total control over the build process.

    Meanwhile, I'd gotten sick of Facebook et al's controls. I pay for hosting, I pay for registration, and I know how to manage my own content—I don't need to be someone else's revenue source. So I downloaded as much of my own content from other sites as possible and archived it locally, and I'm in the process of shutting down my social media presence. This is my home now.

    This, then, is my blog. I have a backlog of topics and to-dos I want to address, so there should be a real burst of new topics as I have time to put things down. I'm not entirely sure what this is going to become, but it's lightweight (static site generated using Middleman), and it's mine.

    1. As I understand it, liquid is intended for things like storefronts where you don't want the store owners having the ability to break things or to access a full interpreter via templates. I don't care, so it's not right for my needs. ↩

    6:12 PM - 11 Dec 2017 in journal
  • Ducks in a row

    Yesterday, Tommy asked to sit down with each of us at some point this week, to see where we are and what we're working on. I grabbed the first slot, and basically asked him "so, what are we supposed to be doing this week?" The list of tasks is pretty daunting at the moment, but today I feel like I'm getting a better handle on everything that needs happen in the forthcoming weeks.

    In short: I need to figure out how to best identify jobs to apply to, I need to compile those into a "roadmap" of places to apply, I need to (at some point, starting next week) apply to them… and to prepare for that, I need to get my portfolio, resume, and cover letter together.

    Speaking of that, I did some work on my personal website (where you're reading this) (ed: this is no longer true; I'm on a different site now), and learned quite a bit about how Wordpress works. It's okay, but I still kind of hate PHP. In time I'll probably get it more to my liking, but it's functional now, at least.

    Again, the coming priorities are portfolio and job searching, and how daunting they are! I've decided that I have more to do than Backbone can handle, so tonight I started reading into Marionette. It's not something that happened as a lark; I found myself doing so much repetitive stuff in Backbone, and the solutions I found always seemed to lead to Marionette anyway. Finally, tonight, upon turning my attention to my final project again, I found myself installing three plugins to add functionality that Backbone didn't have and that I didn't much feel like writing… and said, to hell with this, I'm going to do it right.

    It looks like a pretty good drop-in add-on to Backbone, so I'm pretty confident about the possibilities. I told Tommy, though, that I'd have it together by Monday, which is going to take a lot of my time. Here's hoping.

    12:12 AM - 22 Jan 2015 in AppAcademy
  • Can't stop; won't stop

    Well, we officially don't have to blog, do progress reports, or (presumably) even show up at 9 am anymore.<

    Just try to stop me.

    Interesting thing of the day: the new class arrived. Did we look so adorable and naive on our first day? It really does feel like basic in a lot of ways, again notably in the way that a person (or group) can so markedly change in a few short weeks. It feels like forever ago that I was writing nonsense ruby code, like everything is a for loop! Huzzah!, and now I get mildly angry every time I have to write a for loop in JS.

    Another interesting thing I noticed today: I just don't give a damn about reddit. It's been a while now that I haven't found it so interesting, but today there was absolutely. nothing. I cared about. I guess I've transitioned, and it's now time to start reading HN regularly?

    There's so many things I could be doing now that it can be hard to know where to start. I've been doing meta-work: getting my hosting set up (it turns out Dreamhost has a lot of the same restrictions as Heroku, viz. spinning down server instances if they haven't been accessed in a while, so I guess I will have to get a pingdom account regardless), getting some documents together, etc. Planning is a big thing; I think I'm going to have to live by a routine over the next three weeks+, moreso than even before, which means identifying overarching tasks that deserve attention and then tending to them at regimented times.

    One thing that was made abundantly clear last week is that I can't keep not working out. I have the damn bike setup right here! But… I have no motivation to deal with it in the morning, and that's no excuse at all, especially with a) how much my back hurts by the end of the evening and b) how bad for your health sitting, in any shape, is supposed to be.

    A fun part of today: I pulled my resume from dropbox, then rendered it in HTML + CSS, and explored a lot of sub-topics that had tickled my fancy during this course that I hadn't yet had time to look into. I have a whole list of things that I've learned, and a whole list of things that I could spend time learning (pandoc anyone?), but what I learned today is that flexible styling knocks the pants off document-based styling, as in Word or InDesign. I'm sure they have their strengths, but when all you have is JavaScript, every problem looks like it calls for selectors.

    One funny though from today: there are so many different file formats for presenting structured text. I wonder if it would be possible to extract a universal grammar for them all.

    Tonight calls for more meta-planning; I am going to try to slice my day up into hour-long chunks and see about tending to many things each day. We're supposed to have applied to jobs by next Monday, preferably earlier, and I know I have my work cut out for me.

    4:02 AM - 20 Jan 2015 in journal
< prev 14 Jan 2018 to 20 Jan 2015 next >