Author Archives: Sarah Sidlow

Final Project Pitch [Updated]

Leave a reply

What: The SCS Student Life Website will serve as a one-stop-shop for SCS students to learn about professional development events, social activities, or student groups available to them during their time at Georgetown.

Who: All SCS graduate and undergraduate students; non-degree and non-credit students taking courses at SCS. Monitored and moderated by SCS administrative staff.

Why: There is currently no resource designed solely for the student community at SCS. This website will serve as a community-building tool where students can find and communicate with one another, network with alumni, get information on upcoming programs and events, and even launch and manage their own student group pages.

Customizations:

1. Child theme with significant design changes using CSS

2. Simple plug-in to create custom “event” posts

3. Simple plug-in to create custom “job opportunity” posts

4. Contact form

5. Embedded events calendar

6. Custom admin dashboard using WordPress API

Customization Details and Timeline:

  1. Child theme with significant design changes using CSS (TO-DO)
  • What: Using University-approved fonts & colors, edit the style of the child theme so that it is visually appealing and easy to read
  • Why: Brand management will be important for any University-sponsored, student facing site. Making sure the fonts and colors are used appropriately will not only create brand cohesion but ease of use.
  • How: Create a child theme within the htdocs folder and add a .css file featuring at least 10 modifications
  • Timeline: Draft by Sunday, April 7; Final by Sunday, April 14

 

  1. Simple plug-in to create custom “event” posts (TO-DO)
  • What: Posts about events should stand out from blog posts, jobs posts, etc. Create a visually unique “event” post type that features fields such as time, date, place, image, and rsvp link.
  • Why: Events drive student engagement and provide community and professional development opportunities. As events are hosted by many entities within SCS as well as the broader University network, events are often not published in a standard way. This plug-in will standardize all event posts.
  • How: Using the example “reading list” plug-in, develop an “events” plug-in that provides the features listed above.
  • Timeline: Draft by Sunday, April 7; Final by Sunday, April 14

 

  1. Simple plug-in to create custom “job opportunity” posts (TO-DO)
  • What: Posts about job opportunities should stand out from blog posts, jobs posts, etc. Create a visually unique “job opportunity” post type that features fields such as title, employer, application deadline, and link. Possible to include code that automatically removes these posts on a certain date?
  • Why: SCS is a professional school, and programs can provide elite/exclusive job opportunities to students. This is a hallmark of the school, and should be easily accessible to all students.
  • How: Using the example “reading list” plug-in, develop a “job opportunities” plug-in that provides the features listed above.
  • Timeline: Draft by Sunday, April 7; Final by Sunday, April 14

 

  1. Embedded events calendar (TO-DO) [Optional]
  • What: An embedded events calendar that displays event dates, academic deadlines, etc. Styled to match the rest of the site. Possible to add option to add to google calendar? Possible to have this automatically created from the event plug-in?
  • Why: An events calendar will help students visualize important event dates as well as academic due dates.
  • How: Using a pre-existing events plug-in, customize the style
  • Timeline: Draft by Sunday, April 7; Final by Sunday, April 14

 

Time for research: Week of April 1

Writing: April 4-7

Drafts due: April 7

Debugging: April 6-13

Final Live: April 14

Deadlines for local testing: April 14

Deadline for live testing: April 16

Here we go again…

Leave a reply

Week six marked the introduction to PHP, a scripting language which, on its surface, seems relatively easy to understand. But we’ve been down this road before (JavaScript, I’m looking at you), and I know better than to assume PHP will become a stress-and-error-free part of my life as it relates to web development.

In fact, while the first lessons were easy enough, I stumbled over the exercises for While Loops, Functions, and Objects. For the most part, these issues arose from syntax errors, which tells me I haven’t seen or used enough PHP to know better (do you ever just “know” this stuff?).

There was something familiar about the lesson on Objects, though: the idea of public and private functions reminded me of the local and global scope concept from Javascript. I appreciate the literal nature of this concept in PHP—you can just call something a “public function” to designate it as such, rather than relying on its placement within the code as you would have to do with JavaScript.

A note about learn-php.org: Though it’s not as pretty as Codecademy, I found the lessons easy to navigate and complete. It also serves as yet another example of the web development world’s emphasis on the free flow of information. I’ve enjoyed our little peeks into the world of web development: the importance of community in solving problems (GitHub, Stack Overflow), the “laziness” of developers (copy and paste whenever you can), the preference for simplicity. Halfway through the semester I’m now reminded of some of the takeaways from our Week 0 pre-readings. Here’s to keeping these lessons in mind as we stare down our final project in the weeks ahead.

An update on the midterm profile assignment: I found my subject, VM Vaughn, through this article on Medium. Vaughn began learning to code at the age of 56, and told me before our interview that he doesn’t consider himself to be a “real web developer.” I was anxious to talk to him about what impact his age has had on his experience learning to code, and what, exactly, a “real” web developer is, anyway. More on that later.

Well, that escalated quickly…

1 Reply

I honestly didn’t expect to have so many issues with this week’s gallery assignment. I totally understood the HTML that we built in class, and could follow all of the granular steps laid out in the JavaScript pseudo-code. Yet when it came time to fill in the JavaScript with actual code, I was at a loss. Sure, I could create a close approximation to what I thought it should look like, but I know that so many things can break code, I was sure I was leaving out critical details. I also found myself missing the instant gratification that Codecademy provides in its exercises: there was no little teal check-mark to tell me I had done something correctly and could move onto the next stage with confidence.

Process and Further Questions

I finally found a resource that helped me work through the structure of the JavaScript. It approached the problem in a slightly different way than we had built using our pseudocode, but it explained each piece of code well enough for me to understand how it worked. Yet, when I plugged that code into my .js file, it still didn’t move the slides! At this point, I wondered if maybe the problem was that the JavaScript wasn’t appropriately linked to my HTML file.

I asked one of our web developers to take a look at my project, and he said that I wasn’t referencing jQuery in my HTML, so he helped me add a line of code.

But I didn’t remember having to link jQuery to the HTML in addition to linking the local JavaScript file. Is this something we have to do when using jQuery in our projects?

Also: are there better/alternative ways of testing JavaScript than pulling up the HTML in a web browser? I’d love to believe that some of my issues stemmed from the browser window not refreshing properly, but I doubt that’s really the case.

On feeling organized

I didn’t. Usually, when I’m writing, I have no problem skipping over a challenging section and returning to it later (in fact, I saved the introductory paragraph for this reflection until the end). But with code, everything feels contingent upon everything else. I’m not yet able to see functions as contained “chunks” separate from one another, and had a hard time creating new sections without finishing previous ones.

My research also felt scattered. It turns out, opening 9 tabs with similar google questions and YouTube videos isn’t a helpful way to work through a coding roadblock.

Because of these issues, I also felt extremely disorganized committing my changes in GitHub. There was so much trial and error going on in the .js file of my project that I was afraid to see what the GitHub history even looked like. By the time I got something to work, I had a hard time articulating the theme of what I had done in order to commit it. Moreover, I can’t even imagine what my complete repo history looks like now—I’m sure I won’t be able to easily retrace my steps. Practice, I guess…

$(“#iFeelBetter”).kindOf();

Leave a reply

This week’s jQuery lessons came as a relief following last week’s focus on JavaScript. jQuery solves a problem that I’m glad to learn was more universal than just my own shortcomings: the JavaScript language is bulky, the syntax is confusing, and small mistakes are easy to make.

Unfortunately, using the jQuery library doesn’t eliminate the possibility for error, but it does render errors much easier to locate and address. Hooray for jQuery!

The biggest challenge

The exercise I found most challenging had to do with the DOM. I wasn’t expecting to have such trouble with it—I understood the basics of parent-child and sibling relationships within the context of HTML—but I found that using the DOM jQuery methods to reference various elements abstracted the code to the point where I had trouble remembering what I was supposed to be doing in the first place.

I can understand how jQuery selectors are useful for referencing specific areas of code, and how jQuery actions simplify the code that would be necessary to make things perform the desired behaviors. I also understand that utilizing the parent-child HTML structure by referencing it in the JavaScript makes the code more dynamic—that is, as things within the code change, the JavaScript functions will still apply.

Yet for some reason, using the .next(), .children(), etc. methods just felt like a big riddle. Onwards to more practice, I suppose!

Fun facts

This is just nerdy, but I was really interested to learn that the common case used in JavaScript is called “camelCase.” I had noticed its structure in earlier lessons, but didn’t know anything about it. Apparently, it’s named for the shape of a camel’s humps—with each hump representing a new capital. Of course, we’ve all seen it used in cases like “iPhone and eBay.”

A side note along this nerdy grammar thread: Is anyone else frustrated with Codecademy’s consistent misuse of “it’s” when they mean “its”?

What’s next?

In addition to putting out feelers for our midterm web developer profiles, I’ve been giving some thought to what shape I want my final project to take. At Georgetown SCS, we have a number of WordPress microsites that serve specific populations. The Hoya Professional 30 and the SCS Commencement site are two examples of projects I’ve launched. There is a nascent desire among the administration to launch a student life website dedicated to events, social resources, and student groups here at SCS. I think this is a project I’d like to take on in order to test the new development skills I’ve learned. The major hurdle I’ll need to figure out is the hosting (the other microsites are hosted through Georgetown Domains, which limits the themes and add-ons you can use).

More to come!

Dear Duolingo: Consider adding JavaScript

1 Reply

This week I realized that I have begun learning a new language. Reflecting on my past language-learning experiences, as well as my former brushes with code and query languages, will help me set realistic goals and expectations for this new challenge.

One thing stands out to me as being immediately familiar to my past experiences: I know what the code supposed to look like, but I still have trouble constructing the right syntax on my own. The end-of-unit quizzes highlighted this tendency. I usually got the syntax questions right on the first try (just because they looked right), but I struggled with the questions designed to explain why something is done. That is to say, I’m better at reading the code than I am at writing it.

This week’s lesson with the JavaScript console also reminded me of Data Reporting, where we learned the basics of MySQL query language. I remember when I started learning about MySQL that the process of writing pseudo code was critical in the writing/development of more complex queries. It’s also a great mental/emotional strategy when you get frustrated with writing code, because it’s pretty hard to get it wrong, and it helps you organize your thoughts. I’ll definitely be taking the extra time to write pseudo code and add comments to my code as it grows, just to save myself some aggravation.

Goals for the Future

If “getting better at JavaScript” is too broad a goal, I’d like to prioritize getting better at reading the error messages. When I was learning how to use MySQL, the error messages were immensely helpful at identifying syntax and other input issues. In the Java console, however, I’m still at a loss. Luckily, I’ll have plenty of opportunities to practice reading the error messages, because I anticipate I’ll be generating a lot of them in the weeks ahead.

Is there a Duolingo option for JavaScript?

A Question I’m Afraid to Ask…

It’s clear that so far we’ve been creating variables and functions, and then defining them within the code (i.e. the user’s name is “Cole” so let userName = ‘Cole’. But when we interact with web pages in the wild, that name field picks up data from our user profile. What does the code look like that pulls data from another source and into the field we’re using?

Welcome to my MySpace

Leave a reply

Good Design(?)

Well, I made my first “homepage” using HTML and CSS, and I have to admit I was immediately transported back to my parents house in the early 2000s. I never used MySpace, but I loved Xanga, a blog-based social site that allowed users to edit their own code. I spent hours researching the correct HTML for important things such as:

  • Background music that played when a user visited the site
  • Cursor options that transformed the mouse into small animals and objects (there was likely malware associated with this)
  • Font colors and styles, etc.

I imagine for many students my age, this was the first experience with HTML they had. What struck me the most in this week’s homepage repo assignment was how complex a simple, elegant web page must be behind the scenes. Yes, it was relatively straightforward to change my font to Comic Sans and add a gif of Neil Degrasse Tyson. However, those notably beautiful webpages (Atelier AM, American Documentary, and others here) must have been painstakingly designed to be beautiful on a range of devices.

CSS Stylesheet

I decided to link an external stylesheet to my HTML file, rather than use inline CSS stylings. The Codecademy exercises on CSS made me appreciate how quickly CSS styles can accumulate, and how much more organized it felt to have them all in one place. (Though I will admit I wished Codecademy had hinted to alphabetize the styles for ease of use—which seems like a no-brainer best practice.)

I struggled for a while figuring out how to link my stylesheet to my HTML file, and finally realized it was a combination of incorrect href syntax AND incorrect CSS syntax, so that even if the files were linked, the changes weren’t appearing in my test browser window.

After a few episodes of trial and error, I was ready to give up on the separate stylesheet and just add in-line CSS styles, but I knew that for my final project I would want them to be separate, and I would be better figuring it out now rather than later. I’m glad I did.

A note about GitHub:

I can appreciate the utility of a tool like GitHub to manage the uncountable tiny changes and bug fixes/additions to code. The mechanism of committing changes is simple enough to understand, but I’m concerned that the more changes you commit, the harder the code is to actually read. It takes practice, I guess…

Why is the web inspector editable?

Leave a reply

The thought of someone sitting in their home rewriting the headline on the front page of a newspaper makes me cringe. Why then, is it possible for me to go to Sir Ian McKellen’s official webpage and change his background image to that of a cat in a turkey costume?

It’s obvious that the web inspector tool is useful for learning how the building bocks of code and style interact. I can also understand that it may be helpful to inspect the code of a website in order to debug it, or to be sure that it doesn’t contain malicious material. But I can’t think of a lot of reasons why it should be editable to the point of replacing McKellen’s face with Turkey Cat’s.

Regardless of the reason, it reveals a few things about the personality of web development, and perhaps of web developers themselves: they are tinkerers. In using Codecademy for the first time, I was reminded of how genuinely rewarding it is to achieve tiny victories in code. If you’re not de-bugging to figure out a past mistake, you’re often pre-bugging to see if (maybe) you can get something right the first time. Because of this, it’s important to break the code components (and the expected behavior) into its smallest unit.

For that reason, I’m also excited to begin becoming familiar with GitHub, which operates a bit like track changes for large pieces of code. With each small unit of code and expected behavior, new opportunities for error and unexpected outcome are introduced. Thus, the ability to isolate small changes and to keep a clear record of edits over time is extremely valuable.

But I’m still not totally convinced about the web inspector tool…