Author Archives: Sarah Sidlow

In the end, it’s back to basics.

It’s so hard to believe this semester has come to an end.

When I entered this class, I wanted to enhance my knowledge of HTML and CSS (the only two coding buzzwords I could come up with at the time), and become more adept at communicating with the web development teams I work adjacent to. During our wrap-up class period last night, I realized how much further we had gone into the world of development—to varying degrees of success.

I’ll be finishing up my degree this summer and transitioning to a new life and new job shortly thereafter. As I’ve begun to seriously consider what my new options might be, I’ve noticed a lot of jobs that list basic web development skills in the nice-to-have category. In my own hiring experience, I have always responded well to communications specialists who also demonstrate basic coding skills.

Given this, I’d like to go back to some of my first goals for this class. Rather than develop a plan that will make be a better “web developer,” I’d like to focus on gaining real competency in some more basic things that will make me a stronger communicator. I’ll prioritize CSS as a first step, and hope to become really facile with the syntax and also in my understanding of everything CSS can manipulate. (Sorry, it doesn’t look like I’ll be creating any CSS paintings any time soon…)

I plan to go back to the Codecademy lessons we completed in class, and will likely look for additional tutorials on YouTube and Lynda as I find the time. Because CSS “clicked” for me at least a little bit the first time around, I’m hopeful that I can maintain a comfort with it as I make it a part of my regular practice. This will coincide nicely with a Design Communications course I plan to take this summer, where I will study the fundamentals of functional design as it relates to print and digital publishing.

I’m hopeful that I can continue to work and learn alongside development and design teams in my new role, whatever that may be, so that I can continue to learn this new language I’ve been introduced to.

Thanks for a great class and a challenging semester!

Murphy’s Law?

It always seems like the closer you get to finishing a big project, the whackier the obstacles in your way become.

When that time comes, I always find it helpful to clearly define my priorities—what needs to happen, what’s do-able, and what’s nice to have. This week, priority one was getting my live site up and running. Surprised? So was I.

I hadn’t looked at my project for a few days. I thought a full step away from the project would give me the energy I needed to finish the final push. But when I logged on to take a look at my site, I saw nothing but the WordPress White Screen of Death. Nothing on the front-end, nothing in the admin.

And that’s how I learned to pull out error messages from the apache_error.log file. After a quick google search, I learned that that was one of the best places to look. I also restarted my server, and realized I couldn’t connect. Queue the next half hour with the EasyWP support team.

Long story short: my site is back up and running, and I only lost a few hours of working time.

But I realized something heartening. If this had occurred a few weeks ago, a month ago, a semester ago, I don’t know how comfortable I would have been conversing with the support team. But I did it! I had done my research, I had concerns that I could articulate and I could answer the questions they asked me. That’s a skill I know I can carry forward in my life and career.

As far as progress on my site is concerned, I’m trying my best not to break things in the process of fixing something else. I’ve fixed a minor menu issue and have a fully-functional Jobs plug-in. Work remains on my Events plug-in, and I’ll need to decide whether to prioritize a bug-free plug-in over one with all of the bells and whistles, but that might not work.

Thank you to everyone who provided feedback on my site. I really appreciate everyone who took the time to give it a look, and have added a lot of those suggestions to my list.

Making the Deadline

All semester, Greg reiterated the importance of meeting the deadline, even if the final project isn’t perfect. This weekend, I met the deadline; and my final project is far from perfect.

But I’m happy about where I’ve ended up this week. SCSstudentlife.com is a good start for what may someday be a widely used resource for current students. It features a job board and events page (my two custom post types) that will streamline information from various sources within the school and across the university and its corporate partners. I look forward to demo-ing it for our class to get their feedback not only on my project, but also on the resource itself. (Please be kind!)

I’ve created a custom 404 error page and custom error messages for when users use the search function. I’ve added Georgetown-branded styles using a CSS stylesheet and a child theme, and added two custom post types that receive different information via metaboxes to ensure that each custom post type (events and jobs) display uniform and complete information. The goal of this project was to create a user experience that simplifies and consolidates information for students.

I’ve learned a lot.

Of course, there are still bugs. I had a hard time getting the data in my custom metaboxes to save, and sometimes the data doesn’t display on the front end of my page templates. For some reason, the live site doesn’t look exactly like it did in the local environment. Some of my modified reading-list code is messy. And, of course, the whole thing could use a better design eye than mine.

But, given the time, I think I could fix these problems—I feel more comfortable reading other people’s code on GitHub and Stack Exchange, and I understand how the pieces of my website communicate with one another. I can articulate where the problems are. I’m still a novice, but I’m beginning to feel comfortable speaking this language. Here’s to another week of refining, and a finished project we can be proud of!

I can’t wait to see everyone else’s project.

PSA: Clear Your Cache

This was another week of bits-and-pieces work on my final project, scsstudentlife.com. I’m starting to feel more organized about my workflow, and can better articulate for myself specific problems I want to solve (and specific features I want to add). I’m sure there will be a long wish-list at the end of this project. In fact, there’s a wish list at the end of this post. But I also want to share two tips I learned this week.

Add content for clarity

Even though the site content isn’t a huge part of the assignment, I started having trouble assigning custom CSS to my skeleton site. Filling out the menus and adding a few posts for each post type not only boosted my confidence, but gave me a better sense of what the final live product will look like. Plus, you might find that you don’t like some of your custom theme choices when you see them en masse.

Clear your browser cache

I spent a good amount of time trying to troubleshoot my custom CSS. I would save my Sublime Text file, refresh my test site, and nothing would change. Finally I realized that the data on my test site was cached! Duh! I cleared my history on both browsers that I’ve been toggling between (Firefox and Chrome) and was relieved to see my latest changes finally visible. The final check? I opened my site on my phone.

Questions for the next workshop (minimum viable product)

  • My custom post types are working, but I’ve noticed that the data entered into the metaboxes doesn’t display on the post. I’d love to make those visible and searchable.
  • I made a custom 404 error page by copying the PHP file from the parent theme and adding custom content. I’d like to be able to use the same content for the error page that appears when a search term can’t be found, but I’m not sure where that code is…

Wish list for the future

  • A PHP/jQuery connection that would automatically add new “event” posts to a separate event calendar.
  • A method to organize events by event date, and to remove past events.
  • A “new!” indicator for job posts fewer than two weeks old.
  • Multiple admin levels for use by a team of people, preferably with some built-in approval workflow.

The first week of final project work…

I spent the weekend working off-and-on on my final project. When I sat down for my first intended work session, I felt immediately overwhelmed. I’ve never taken on a project like this one before. There were too many apps to be aware of: GitHub, MAMP, FileZilla, a tab of local WordPress testing, and a tab of the live site. Not to mention tab after tab of “how do I…” queries.

But as I spent more time on this project, I noticed more and more similarities with the work that I’m used to doing. For one thing, you can’t do it all in one sitting; you have to get up and move, to do something else, walk away and return. For another, there won’t just be one unfinished project; there will be many unfinished sections—the same way you move on to another paragraph when writing, even when you know you’ll have to come back later to tighten the language, add more context, or reassess the flow.

I’ve made some progress, but it was slow and buggy. I was elated to see that I have two functioning custom post types appearing on my life WordPress site. Then, I was immensely frustrated when I couldn’t figure out how to display those post types. I started working on my custom CSS as well, but didn’t get too far with it, because I thought I needed to add more content before I could really decide what properties I wanted certain classes and IDs to display. Back and forth, back and forth.

I’m coming to class with a lot of questions. But at least having questions means I’ve made some progress. Here are a few:

  • I copied the custom post type code from the Reading List example, but I can’t figure out how to add more than one meta box. When I tried simply duplicating the code, I threw an error on my test site: “invalid post type.” Undo, undo. Save. Walk away.
  • I have two custom post types built into my live site now (yay!): one for event posts, and another for job posts. I was hoping I would be able to use CSS to differentiate these posts visually, but when I refreshed my site, I couldn’t even figure out how to display these different posts! Research, research. Over my head. Save. Walk away.
  • I also have some wish list items that I imagine would be relatively do-able, but won’t focus on too much because I’m not sure they’re feasible with our timeline. But I’ll ask here, anyway: I would love a feature that would connect the data from my “event date” meta box to a calendar widget elsewhere on the site. That way, each event would appear both as an independent post, and as part of a collective calendar. Is this possible? And how hard would it be?

So many questions…

APIs & Agile

API Lite, Please

The first two readings this week helped solidify my understanding of what an API does: It’s the mechanism by which a client communicates with a server (like a waiter taking an order from a customer, retrieving it from the kitchen, and delivering it back to the customer).

The second two readings, on REST APIs, completely blew my mind.

In addition to taking and delivering data, APIs can also post them. Moreover, you can make API requests in a browser to view JSON data specific to your query, including specific parameters that you control. Then, you can take the data you mine from an API request on one website, and use it to access or reference additional data on another website! This waiter is multi-talented!

It does bring up a question for me about security, however. I know that access tokens must be passed to authenticate that the person accessing the data is allowed to access it, but do systems become vulnerable for malicious data scraping when their APIs are available on something like Apigee? This goes back to the recurring theme of developer tools being transparent and accessible—from web inspectors to API management software—while also being acutely aware of the risks of the internet.

Back to Agile Framework

Since Week 8’s discussion of agile frameworks, I’ve been paying more attention to how teams in my workplace function. I remembered that one of my colleagues, who works as a project manager for the marketing and technology teams, had regular “scrum” meetings on her calendar. I asked if those teams operated under an agile structure, and she (impressed by my question) responded that yes, our Chief Information Officer prefers to operate that way.

She explained they work within a framework that’s most similar to scrum, with sprints (a blend of technology and design work) lasting 10-15 days each. It’s interesting to think about this technology culture being nested within the framework of higher education, which operates on a much more drawn out and fluid timeline.

My colleague noted that, while projects aren’t always strictly within the set scrum framework, it’s been helpful for the members of the team to operate using a common language and set of expectations, and the framework has allowed them to complete a lot of high level projects with success.

She also mentioned that she uses the tool MS Project, which allows her to help the team visualize the consequences of contingencies and dependent tasks not being completed.

Learning the Command Line

We’ve covered a lot of ground in the past week—from remembering (maybe) PHP, to diving into WordPress child themes, to being introduced to Command Line operations. I’m excited to put all the pieces together in our final projects, and have found myself thinking more like a developer in my daily work life. For example, yesterday I wondered if I could code something that would update a broad communications calendar based on the date of the annual event. I’ve also become more conscious of using copy+paste to reduce errors and documenting granular changes that have been made to projects with multiple stakeholders.

Learning the command line

I was first introduced to command line functions in SCS’s Data Journalism class, which introduced basic commands to illustrate points about how the language is constructed and what functions that are possible within that scary-looking terminal you’ve never tried to use before. Some of the language functions also reappeared in other databases like MySQL. This week’s reading was a good reminder of what can be done (essentially, everything that you can do using Finder), but also about how foreign it feels to use.

One new piece of information I found interesting was the man command, which gives you additional context about the command you’re referencing. I predict this will become a super useful tool while learning about and using the terminal in the future.

Another helpful tool referenced in the reading, https://ss64.com, contains a complete reference of commands for all operating systems.

To be honest, though… 

While I can see the utility in understanding how to use the terminal, and the command language it accepts, I don’t see myself changing my behavior to use it over the finder window. For some reason, I especially find the idea of deleting something from the terminal distressing—it just feels less tangible than clicking on the file/folder and deleting it.

I can’t wait to be proven wrong.

Design Thinking and the Return of PHP

Reflections on the Homework

This week’s homework was a good reminder of how fast a skill can atrophy in the face of Spring Break. While searching for the simplest PHP features I could find, I realized that I still don’t really know how PHP interacts with the base of a website’s HTML. I understand that PHP is a server-side language that can create functionality on a website that HTML can’t do alone. But  I never stopped to consider how the two languages “talk” to one another.

I took to Google, hoping for a quick bit of code similar to the one that you use to link a CSS stylesheet to an HTML page. No such luck.

What I found were forums with varying opinions on whether you could code PHP directly into your HTML file. The conclusion I drew was that it’s best to keep files separate (hello, Separation of Concerns), but, like CSS, PHP can work when referenced directly in an HTML file.

I also learned that in order to get the PHP functions to show up, you need to be hooked into a server (makes sense) or server software like Apache. I’m assuming this is where something like MAMP comes into play, but to be honest, that’s where my train of thought ran out of steam.

So, here are some questions I still have: What’s the best way to set up a local server for simple websites like our homepage repos? What’s the best way to test the specific functions of a PHP script? And how do you reference your PHP file in an HTML file?

Readings on Design Thinking

Switching gears to focus on the future, for a moment. I’m grateful to have had these reminders about good design and user experience as we begin to plan out our final projects. I found the Medium reading, “Shh! Don’t Tell Them There’s No Magic In Design Thinking,” particularly interesting, because I hadn’t thought about the tenants of Design Thinking in that way before—i.e., the concepts have been part of good development forever, but now people are starting to pay attention. Here are my favorite mantras/takeaways, which, consequently, are the ones that I think will be the hardest for me to master:

  • We’re going to do things differently from how we’ve always done it before.
  • We’re going to study problems before we jump to solutions.
  • We’re going to diverge on our best ideas before picking the one that matches the solution best.

Where the Rubber Meets the Road

We’re halfway through the semester, and it’s time to start thinking critically about our final projects. This week’s readings (plus the extra time to think thanks to a well-timed spring break) reminded me that the time for thinking abstractly about these new concepts is coming to an end—it will soon be time to put the lessons we’ve learned into action.

I know that I want my final project to be a micro-site for student life and community-building here at SCS. In our final project pitches, we were encouraged to spend more time on the “what,” rather than the “how.” But reading about WordPress child themes has started turning the “how” gears—just a little bit.

Here are my takeaways:

  • The WordPress theme we create can’t just be about changing the site’s appearance; “Good themes improve engagement with your website’s content in addition to being beautiful.” But themes also shouldn’t bear the weight of adding functionality, because when a user changes their theme, they lose access to that functionality. So, then, are good themes just based on good design thinking? What does that look like, and how can you test it?
  • The functionality should instead be borne by plugins, which ensures that a site’s functionality can remain consistent, even if its theme changes. But with so many useful and well designed plugins already in existence, how can we hope to build a new one that would be better/or different from one that’s already been published?
  • I’m most excited about the idea of incorporating metadata and meta boxes into my child theme, because I think it will help alleviate the consistency issues that can arise when a site has multiple users. For example, if the student life page is opened up for student contributions, creating a certain number of required, customized fields will ensure that the content looks and feels exactly the way it should. Since meta boxes can be changed depending on the user, it may also provide increased functionality for “admin” users of the site.
  • Debugging: “Configuring debugging is an essential part of WordPress theme development,” the reading says. This will be critical for us to deploy in order to maintain functionality of our sites. I also anticipate this becoming a source of frustration…

I’m excited and anxious to see how this final project shakes out, and how much I’ll have to compromise between my wish list and what I can realistically create. Remember, self: simple is better.

At 57, He’s Learning to Code. Will it Become His New Career?

Mike Vaughn will be the first person to tell you he isn’t a “real” web developer. But at 57 years old, he’s learning a skill often associated with teams of 20-somethings: how to code.

Vaughn has been around computers for the last 37 years, before the proliferation of personal computers and back when processing was done by one mainframe computer connected to a number of terminals. Back then, his job involved using a low-level assembly language to develop software that ran system mainframes.

Now, he works as the director of professional services for a software company, installing software, teaching clients how to use it, and troubleshooting when things go wrong. He oversees a team of developers who work to develop product updates and improvements. When his job duties expanded to include development, Vaughn saw an opportunity to learn more about the code that makes the software work.

“I really got enthralled with it,” Vaughn said during a recent phone conversation. “I got excited again about the idea of programming. Even though I’ve done so many things with computers—management, consulting, technical work—I’d never really programmed. And it just became so apparent to me that this is really cool.”

In 2016, Vaughn started using FreeCodeCamp.org, a free online learning platform dedicated to teaching people about web development. But self-directed learning can be a challenge, especially when the topic is akin to learning a new series of languages.

“It’s not a natural thing,” Vaughn said. “It’s a very esoteric thing in terms of the language and translating what you’re trying to achieve into that language. You have these errors and you just don’t know why it’s not working, you’re googling everything you need to google.”

JavaScript, especially, has been a sticking point for Vaughn.

“In terms of my progression in web development, it’s been really start-stop,” Vaughn said. “And that’s just because, you know, I get into learning HTML and CSS, and then I get into JavaScript and then I just fall off. And then I pick it back up and fall off.”

But he’s completed small projects—a matching game that functions using a combination HTML, CSS, and JavaScript, for example—and has learned the lessons in persistence and problem-solving that all developers learn in time. Luckily, Vaughn said, the resources available to today’s developers far surpass those that were available early in his career.

“I came from a world in 1982 where you had a library of manuals that you used to look up error codes,” Vaughn said. “There was an internet, but there was no world wide web like we have today. Today, the resources are tremendous. You can just google the error you’re getting.”

Vaughn also recommends learning to use Chrome developer tools early. The console view allows users to inspect the elements of a webpage, which can help them to see how their code is behaving in a test environment.

“And if you still don’t get it,” Vaughn said, “you can always google that. The chances are when you google that exact error, you’re going to be take  to a site called Stack Overflow. Chances are, somebody has already answered that question.”

At work, Vaughn manages a team of software developers—most of them younger than him. Occasionally, he interrupts their work to learn how they’re doing it. He said while they’re all more facile than he is at using their smartphones (Vaughn sticks to phone calls and the occasional picture), there isn’t much of a difference in the ways they approach problems.

“Whether it’s a digital native or a boomer like myself, there’s a mentality of ‘Let’s figure it out, because we can figure it out,’ ” Vaughn said. “We have the tools to come up with a solution or an answer. I think that’s probably a common thread for anybody that is still vibrant in technology—regardless of age.”

Working with his team has also allowed Vaughn to explore whether, as he enters retirement age, he really wants to build a second career as a web or software developer. As of now, he’s focused on building a portfolio that can lead to freelance opportunities.

That means there’s still time for him to become a “real” developer.

“Freelance is a viable way to make an income,” he said. “So if I sold a freelance project where I developed even a simple website for a client, then at that point, I’m a web developer.”