Love (for the Pine Barrens) in time of Covid-19.
Otherwise, so much indoor time reading, coding, and video games. Trying to stay off Twitter and slow down the news.
This website will soon disappear. You can check out my new site as I develop it.
♥ S
]]>
Here’s me at Nockamixon State Park a couple weeks ago. Hot weather hiking is the best!
We recently participated in 2017 Code4PA Hackathon and our project has gotten some attention from the governor’s office. Check out our post on its current status
]]>Click on the arrows to see what I’ve explored:
I started by watching as many of Dan Abramov's conference videos and doing the tutorial on the official React site.
I then read through the MDN Web Component docs to learn how React wraps existing HTML features.
After that, it was a matter understanding the props and state cycle. I'm still working on using the component lifecycle methods best, and I look forward to using the new Context API.
Check out my baby single-page app made with React + React Router: Really Philly. My goal is to work on it some more and open it up to interested local developers.
Up Next: rewriting my existing weather app, drizzl, in React.
I've always been interested in game design, so I downloaded the Unity engine and did the roll-a-ball and space shooter tutorials.
This has been a great introduction to C# and asset scripting, and I'd like to work on this kind of programming in the future, either for game design or animation. VR would be cool.
Space can be so very lonely.
I had heard awesome things about Elixir, including its humble origins as a telephony language. Back in bootcamp, I put it on the list of topics to explore when I got some time.
I decided to start chronologically, back in the early 1980s, and I read about Ericsson's problems with their contemporary telephony code. This led me through the Erlang documentation and Erlang: The Movie. (Definitely check that out.)
I found an awesome exercise, Elixir Koans, and a couple Phoenix tutorials.
My favorite Elixir feature so far is pattern matching, as seen above.
I've come to realize I'm very much interested in back-end development, specifically in CI/CD engineering. That's not something I can easily practice outside of a professional production environment, so I've taken every opportunity I can find to learn.
Recently, I participated in The Item's Day Zero Hackathon, at which I learned about various approaches to the CI/CD pipeline. I got to drive in my small group and instantiated an EC2 server and installed Jenkins.
Cash Flow PA lives! You can learn more about this open-source project I started with some friends on PhRIG's site.
Our meeting with the Pennsylvania Governor's Office staff went really well! I've documented Cash Flow PA's current development in a separate blog post.
As we rolled out v1, we've decided to shore up the app, which includes writing tests. Here's an example of a couple rspec tests I contributed to this past weekend.
Otherwise, I’ve been cooking a lot, reading (latest rec: Patricia Lockwood’s Priestdaddy), and playing some Overwatch here and there. ¡Apagando las luces!
]]>I recently developed Drizzl, a generative weather-art toy, for my final project at NYCDA’s three-month web-development intensive program.
Inspired by Tero Parviainen’s excellent presentation on generative art, “How Generative Music Works”, I set out to make an interactive app that uses weather data, rather than an algorithm, to inform the app’s visual elements.
I discovered a number of emergent aspects during development. Here are a few:
Discovery #1: The best way I found to create the app’s interactive elements is by procedural generation.
The app first queries the Dark Sky weather API with the user’s location and then iterates through the forecast returned to the client as a JSON object. (If you’d like, you can open the browser’s console and examine the forecast object.) It then generates a button for each forecast key:
The result: there are no statically generated buttons. For example, when I input the lat and lng of the most remote island on earth, I get the following buttons and a pretty sparse animation:
This scarcity of buttons confused me at first, but I now presume the lack of forecast data is due to the low demand for weather (and weather equipment) at that spot. The same happens if you search other remote locations, like Antarctica.
Discovery #2:
I figured out how to shoehorn as many variables as possible into an html canvas element animation.
Learning to make the animation itself was tricky. I started by searching for html canvas animations on CodePen, copying or forking them, breaking them, and then trying to fix them. After about 10 animations, I learned enough to create my own simple particle flow. You can hit up Drizzl’s github repo for the full code, but as you can see below, I implemented quite a few animation variables for interactivity:
To see each of these variables in action, open the console when the app is running and you’ll see messages indicating what each button does.
Discovery #3:
As a novice to web development, but an old (and quite amateur) hand at art, I rediscovered a lesson that consistently rings true: you’re never really done art until you package it up, ship it off, and move on to the next project.
With that said, I began to implement but ultimately dropped effective use of a database so users can save and share forecasts. If you take a look at app.js, you’ll see I’ve already set up an Mlab database, but I haven’t implemented its use. That also begs the question: would users actually save and share their forecasts? I don’t see a reason to do so right now. Maybe if a user could save the state of their interactivity and then share it, they would, but that will remain unsolved until I learn a dynamic view library like React.
Still, I want to point out that even though this is a single page app, the forecast is requested by the server and rendered to the client:
I initially struggled with rendering the forecast back from the server to the client, but I solved this problem by hiding the forecast in an H3 tag, grabbing it, and then deleting the H3 tag:
I have no doubt there’s a routine, elegant solution to this problem, but I like my quick fix for its novelty. That reminds me: a long time ago, I used to work the 6 am shift at a great bakery in Boston. That early in the morning, I rarely had the wherewithal to check the weather. This could be punishing. Later that afternoon, covered in flour, having forgotten an umbrella, I wasn’t afraid to wear a trash bag on the bike ride home back to Jamaica Plain. You gotta do what works.
Thanks for reading!
]]>Our latest assignment is to use the Sinatra framework to create a message board-style app.
My costudents Chris, George, and I finished ours up a day early. Chris and George are great. The class took about a week to get through Sinatra routing basics, but George clued me in to using embedded Ruby (aka ERB) with dexterity. Let’s take a look at the first example:
As you can see in the commentary, George and I made some dynamically-updating buttons all in ERB, without using an javascript. Here’s a video of the nav in action.
Sure, we could have designed a functional, maybe even elegant, solution with some Javascript event listeners, but George’s minimal approach worked even better. It takes up fewer lines of code, less processing power, and it’s all there in one file.
]]>