Category Archives: 2013 Summer class

Humbling Experience

I truly cannot wait for this phase of my journey to reach its end. The class has been quite humbling. It has brought to light those things that I do not comprehend. I mean, there is no hidding, even if you thought you got it, you really didn’t because when you click on view site, what you thought you got isn’t displaying. To top it off, you get a message which reads this is embarrassing. Wow.  Oh, then there is the fix that breaks something else on you site. Totally disappointing.  At this point, I really do not even want to go to my site. It depresses me. I am not a quitter, so I will not be giving up, but I will be stepping away from it for a while. Even if this site ends up just being about random thoughts.

Plan B for my business site. Upon registering for this class my hopes and expectations were to pick-up web-development skills quickly in order to launch a sophisticated interactive site for my business. Boy, was I wrong. I should have applied one of the mantras that I use to apply while in the Army: expect the worse, but hope for the best. My high expectations led to complete disappointment, but at the same time, I have accepted the situation. I cannot afford to be in denial. Time is too precious, so I have decided to call it what it is: WEB DEVELOPMENT and/or WORDPRESS Development is not for me. I like it, but I find myself devoting too much time to trying to find solutions to problems, which at times have been left unresolved because there are not enough hours in the day. To become better at development, I will need to devote more time than I have and/or possibly quit other things that I care about mentoring children, health and fitness, small business consulting and those things that I do to sustain my day job, consulting.

There are plenty of people out there that have a passion for web development, I pray that I find the right one to partner with to create my business site. The theme that I want is definitely innovative and interactive both are far from where my site is today.

Agile is like small unit leadership.

I saw everyone was writing about Agile, so I figured I was on the wrong week. So here is my post for week 9.

I read the “Agile Manifesto,” and then watched the video just now. Needless to say, having missed Tuesday’s class, I was lost. I had no idea what Agile was, and why I was watching the video of this little bald head talking to me. A little Google/Wiki search, and I was on track.

So I think I understand why these developers had the idea to create the manifesto and a non-profit learning academy. I’m sure what they said about the “waterfall” technique was absolutely true. Unlike some other businesses, the business of computing and the Internet came from big government. I’m sure that means they both transferred over to big business, who in turn pushed out software in giant waves that crashed over and soaked their customer base. After all, that’s how big business works. Even Apple is like that … “Here comes the new iWhatever! You’re all going to love it and learn to use it.” They don’t function in small teams like ideas that are built from the ground up function … or at least how the good ones function.

We have a military concept that is very similar. Something designed to save us from big military ideas. It’s called “small unit leadership,” or “distributed operations.” The idea is phenomenal, and basically involves all decision-making authority being pushed to the lowest level of leadership. In many cases, that ends up being a 19-year-old kid. That means he is deciding when to drop bombs, when to attack a building, and when to call in for a medical evacuation. That may sound crazy, but it works. Decisions are made faster than the enemy can make them, because that 19-year-old’s equivalent on the battlefield has no authority whatsoever.

From what I understand, the Agile method is a lot like that. Low-level developer teams interact directly with the customer. They make plans and carry them out based on what the customer gives them. They also implement and follow guidelines that ensure success. If the customer tries to circumvent that process, developers have the authority to guide those customers back, without fear of reprisal from higher.

It sounds like a good method to me. I thought the manifesto was a little much, but the idea of small unit leadership and ideas makes me feel right at home.

Agility & Sprint to the Finish

The concept of Agile Web Development and project management are important to a complex web development project. It helps reduce the amount of miscommunication between all involved parties in the project and it allows for a change of direction. Agile development should also reduce errors, bugs, and mistakes in the code or project. When I watched the video it almost felt as if the screencast host was reading through my old company’s emails.

About two years ago my old employer was losing the battle for total domination of the first search engine results page. The first page was being dominated by customer review sites like Reseller Ratings and Trust Pilot with less than exceptional reviews from former customers. As a new social media analyst with the company, I was placed on a team with the SEO guy and the Marketing Technology team, which included a few developers. The goal was to build a website that showed off the customer service interactions on social media (more specifically Twitter). The project was difficult because it wasn’t a high priority item on the marketing technology team even though it was a fairly simple project using Twitter’s API. We would meet every two weeks but people brushed off the meeting or emailed their updates. The point of contact for the project would change every other week depending on who had more time on their schedule. Instead of the project taking a month (I know now it shouldn’t take anymore than two weeks to use an API) it took well over three months. Should I have known about this agile development concept, I would have sent the manifesto to the project lead to avoid constant headaches. It would have encouraged us to meet more frequently, get information from one source, meet everyone who was on the team, and the team would have gotten a better understanding as to why the project was necessary for the company. You can take a look at that project here: www.wireflytweets.com.

I’m finally done with the www.milagrocleaning.com project from the semester. Although it will never completely be done, since I’ll be adding content consistently to drive traffic to the website, it feels good to have accomplished the functionality aspect of the site. My classmates have asked a ton of great questions that offered up ideas in their critiques and issues section of my github repository that only helped further build out my site. Looking back on these summer months and what I have been able to comprehend is unimaginable. I always understood certain pieces of html, but to the depth that I have learned a little of all these coding languages and how they play a role in a CMS platform like WordPress is unbelievable. We have all complained, gotten frustrated, and struggled, but we’ve all learned great concepts throughout the semester.

This is a quote that has defined the semester for my classmates and I:

“If There Is No Struggle, There Is No Progress” – Fredrick Douglass

UPDATE: Amazon accepted me and the website as an Amazon Associate! Alternate income sources are awesome!

Agile: best practices and being done

The Agile manifesto and best practices video really hit home for me. Remember early on in class when we had all of those glorious ideas about what our websites were going to look it? I initially wanted to build a custom slideshow using JavaScript… and that clearly did not happen. It’s takes a lot of time to plan out and create a personal website, and being realistic about what you can and cannot accomplish in a given time period is critical.

I immediately thought of work while I was watching the Agile video. I work on a project management team that builds a variety of digital programs for various clients. One of the most difficult aspects is getting on the same page as the client, and delivering a product that they truly wanted in the first place. It’s a constant give and take between exceeding the client’s expectations and not going outside the statement of work (putting more time in than we are getting paid to do). The principles of Agile are key to ensuring you deliver a valuable product, on time and on budget.

One of the most intriguing best practices that Jay talked about in this video is how you should only have the team members who are working on the project provides the estimate. I could not agree with this more. At work, we are always running into issues with the sales manager promising things to clients that we simply cannot deliver.

At the end of the video, Jay talks about the definition of done, which takes me back to our class sites. While there is a shared opinion of what “done” means, Jay says that one of the core tenets of agile is that when the team declares the project done, it needs to be in a releasable state. I think this was the ultimate goal for class. Yes, we are never actually done with working on our personal sites — there’s always going to be content and customization to add — but having a site that is functioning and ready to launch means that we are DONE. And right now, that’s a good feeling.

Side note: I’m really happy we went through a critique phase for our sites. I appreciate all of the feedback I received! Getting user feedback is truly an important part of creating a website.

 

The definition of ‘done’

I found the Agile scrum methodology to be quite interesting. The emphasis on following the rules and the critical role of good communication in keeping projects on task was fascinating to me. It was also something that I felt, when applied correctly, could be applied to anything, not just coding projects. I was a little confused by the idea of change however. In the video, it was made clear that mid-sprint, things should not be changed. It throws off the team and leads to potential failure. Rather, goals should be established at the beginning of the sprint and everyone needs to stick with them. In the Agile Manifesto however, it states that:

Welcome changing requirements, even late in 
development. Agile processes harness change for 
the customer’s competitive advantage.

I assume that these two elements of Agile are likely not as contradictory as I seem to think they are but for a novice like me, it still seems a little complicated.

One aspect of the video I found especially interesting, as is apparent by the title of this post, is the term ‘done’ and the many contradictory understandings people have of it. Our website projects are done today but are they actually done? Probably not. They were done last week as well and look at how much more work everyone has put into them! I think everyone has their own understanding of what an assignment being done means. Because of this, it is critical for everyone working together on projects or on the same team to share these understandings to maximize success.

Some last thoughts to leave you all with:

1. I wrote this post entirely in WordPress using the expanded page view Greg shared with us rather than copy pasting from Microsoft Word. It was my first time doing so and although it wasn’t half as bad as I thought it would be, having the page background fade in and out of white while I was typing was incredibly distracting.

2. I had a nightmare last night about getting stuck in traffic and not being able to post an analysis post by 5 p.m. I wish I was kidding.

Critique and Changes Update

The most common critiques were about white space and descriptions for my photos. Unfortunately, I was only able to resolve the latter. I added brief descriptions to the photos that I felt weren’t self-explanatory, or that I thought had especially interesting stories behind them. The remainder of the photos I left at a thousand words…

I wasn’t able to resolve the white space issue, at least not completely. On the content pages, I was able to adjust sizes to decrease some white space, but on a large enough screen the white space is unavoidable. At least as far as I can tell. On the home page, I was able to address the white space a few different ways, but each of them created a new and worse problem. It’s something I’ll have to continue to research and work on, and something I may not resolve before the course is complete. Another suggestion was too bring the image headers closer to the bottom of the image, when viewing category pages. This is something I have struggled with. I’ll continue to work on it, but I’ll probably need to submit the question to a help site.

There was one aesthetic suggestions, which was where to place the home link. I left that one open for now, because even though I don’t want to move the home button location, I think I can draw more attention to it with some styling.

Other issues that classmates brought up were resolved more easily, and they are as follows:

  1. Header not centered on larger screens (resolved).
  2. Like buttons not working (resolved).
  3. Misspelled url on “Architectures” page (resolved).
  4. Unnecessary info above Twitter widget (resolved).

Additional issues I noticed this week:

  1. Admin comment highlighter not working (resolved).
  2. Menu not centered (resolved).

I’m still working on a lot of other things that I’m finding online. There’s too much honestly. I think I’m going to burn out and a year from now you’ll clink on my link only to find the page covered in cobwebs. 🙂

Better planning means less wasted effort

The statement that popped out to me in the video you assigned us to watch is that better planning means less wasted effort. Looking back at my prior entries, I noticed a trend. That trend was that I often mentioned that I should have done something earlier.

This statement can pretty much be applied to anything, but regardless, it is an important concept to keep in mind, especially in code world. The second statement that popped out to me is that it’s important to have a shared definition of done. As DJ’s post says, you’re never really done with your site/project. When referring to agile practices, it’s most important that everyone is on the same page and understands the point in which they are trying to reach. I have kept this in mind when thinking about/referring to my site. There are so many improvements that can and should be made to my site, but all of those changes will not necessarily be made by Sunday. I learned that it is important for me to set a goal of what it is that I want, and just get there. Everything else that may come to mind later on that I want to add can be added at a later time as well.

What I learned most through the reading/video is that the teachings are close to identical to what you’ve taught us from the beginning of this class. We were asked to pick the functionalities of our sites (keeping them realistic) and we were given a deadline. We were encouraged to test them before deadline to ensure all of the bugs were worked out. As we critiqued one another’s sites, we played the user role.

I can honestly say that now that I’ve seen not only my progress, but my classmates’ progress as well, this whole coding thing is starting to make sense to me. Initially it is hard to accept that you’re taking a class that you’ll probably still leave as a beginner in. You repeatedly warned us that by no means will this class make us coders, but it is not until very recently that I was able to piece together the reasons why we did a lot of what we did. I still hate JavaScript, and it may still take me hours to figure out how to fix my broken codes, but I have made so much progress. I understand concepts, how important it is to Google and so many other things that I would have never touched on without the push of this class. And with that being said, me, myself and I have agreed that this post is DONE.

Finishing the project doesn’t mean the end

I am having a flashbacks of error messages from COBOL. The solution is exactly the same for all of them: google what the error code is or what you want to do. Almost every time, someone has been trying to do what you are doing, and has documented failures and successes. It is  encouraging because you don’t feel alone, but also discouraging because you feel that you are trying to slam through a brick wall with your head; it hurts.

I am looking back at my thoughts from the first classes of the semester, and I am not seeing the kind of results that I had optimistically (naively?) put my sights on. But even with not being quite what I wanted to have at the end of this process, it has taught me that this isn’t the end. And that’s a good thing. I remember stating earlier that I didn’t like some previous projects that have lain dormant after the end of the corresponding semester, and I am confident that I will continue to tinker with this puppy until I get it perfect: that is to say, never! This also brings me to the issue of between midnight tonight and class on Tuesday, I will still be working on it to try and keep improving it, I hope Greg doesn’t mind!

I am learning that I don’t really want to be a “web genius” like Zuckerberg or Wozniak, because I do still want to be the journalist writing for the public, rather than one of them writing behind the scenes and changing our online lifestyles. It is laudable, but I want to be finding the stories that people read and get engrossed in. This by no means changes the fact that I find this class extremely interesting and fulfilling. I am so glad that I can now control my own online presence instead of dictating needs to someone else without knowledge of what is occurring. I find it detestable to not know how something works, and that is what will keep me employed as a journalist, and this class makes me even more valuable to would-be employers.

My final project has gone through several facelifts, and I am pleased with how it is shaping up, but I do not think that it is my vision yet. I do not think that it will be there until I completely work out some issues with the Twitter idea, the way for the blog to situate itself, and other ideas I have. I have come to the concession that I will probably find things I want to change about it every time I look at it.

Coding Under a Deadline

To say that I should have been coding a lot more along the way is an understatement. I focused more on the content of the site as I received it and I think they’re really great pieces. There’s nothing like a deadline to push you to code briskly and checking your work along the way. After crashing my site by messing up a few lines in the functions.php file, I had to walk away from the site on Friday afternoon. It was getting to be a bit much and I felt like my jQuery-hating self again. Oftentimes, the best thing you can do after much frustration is to walk away from the site for a few hours. Clear your head and come back to the code and really go through it with a fine tooth comb.

I took a little more than a few hours and really got myself mentally ready to engage in a full day of coding and content creation. The site visually I think is awesome compared to the bare bones it was a few weeks ago. I’ve seen the site come a pretty long way and I am proud of what I have been able to learn and code. It wasn’t without the help of Codecademy to remind myself of punctuation and proper order. My biggest appreciation for what this class has taught me is literacy. I remember looking at .php files in WordPress and not knowing what did what and how. I’ve now been able to dissect pieces of codes and understand what it does based on context. I won’t claim intermediate proficiency in my professional life. This, however, was never the goal and my ability to understand code and the website creation project lifecycle is a very valuable asset to have as a marketer.

There are few loose ends to tie before the midnight deadline. Mostly exporting my content from the local site to the live site and making sure everything looks in order. I can’t wait to see everyone else’s projects and get another perspective on my own to strengthen the final product. See you all Tuesday!