Writing Web Pages

HTML isn't that hard to pick up. In fact, it's probably the easiest thing I've learned in several years. That said, writing web pages can get exhausting if you don't do it right the first time. For example, it took me about a couple hours to write a simple web page, but it took another 3 hours to correct the mistakes that I made on that same page. So, it took me 5 hours to complete something that should have taken 2. I'd like to note that this kind of mistake didn't just occur on one of the web pages; it occurred on all 10 of them. If I averaged it out, that's a loss of 30 hours of productivity. Fudge.

What have I learned? Do it right the first time. That means finding out exactly what the publisher wants me to write and, of course, writing HTML in the correct format, from the beginning. This lesson can be utilized throughout my career in programming, as I begin to utilize Ruby, Ruby on Rails, and other programming languages and methodologies. The less I mess up in the beginning, the less I have to do later. Sounds simple, but there is a lot to learn in the beginning. Putting in that initial work will pay off in the long run, especially if you value sleep.

Cheers

Ruby Conference Notes (first part)

This post will also be on the Hybrid blog; check us out!

http://blog.hybridgroup.com/

Ruby Conference

A. Keynote Address by Joe O'Brien from EdgeCase

Things that you need to start a successful start-up:

1. People

2. Technology

3. Process

Apparently, a project never fail or succeed for technical reasons. It’s all about the people. If you have freedom to express what was going on, your project will succeed.

Start learning psychology. Learn people patterns.

Conversation rolodex. Voices in your head: They Don’t Go Away – Negative voices that are actually self-defense mechanisms that prevent you from validating your self-doubts. It’s a lot easier to confirm your doubts, than destroy them.

What Do They See?

-          Apparently, improve helps a lot.

-          Client sees people who don’t care, if you’re on the laptop or doing something else.

-          Presentation is important. You have to show yourself as being professional. Also, make sure you’re communicating professionally and properly. Make sure you go over points correctly. Show up on time and make sure you communicate well.

The Three Realities

-          There are always three realities: what you see, what the other person sees, and what the real person sees. Objectivity is near impossible. You can’t look at something without mental baggage, so to compensate, you just have to attempt to understand the other person’s perspective and to know that you’re looking at something subjectively. Try to look at the other side and what his/her problems are.

Listen Without Agenda

-          So excited about a conversation, you start thinking about something related to yourself, instead of listening. These are things that are going to happen, but you have to be aware. ie mindfulness. If you catch yourself off in another world, just understand that you’re doing that and come back to the real world.

Bad News

-          It’s an acid that hurts you emotionally and physically.

-          Resolution: Reveal bad news quickly. If you discover something is wrong, don’t let it fester. Start acting upon it immediately. People don’t expect you to have answers, but they expect you to take the steps to correct the mistake.

Uncompromising Honesty

-          If you screw up, tell them that you screwed up. Being nice and not really telling them does not help. This is important, especially if someone is asking for feedback. Hiding something to make someone feel better doesn’t help, but neither does being a jackass and overly critical. Find the happy medium.

Listen Between the Lines

-          Pay attention to why people are asking questions. There are many subtle things in life that people won’t be direct to you about. This is why retrospectives are important.

Assume The Positive

-          We build up walls, psychologically, because we hate to be let down. If you keep assuming negatives about things, you will give off an air of negativity. There are some let downs, but more positive things happen because of it. People around you warm up to who you are and build into your ideas if you’re positive.

-          Improv – “Yes, and..”  Don’t immediately shoot down an idea. Give things a chance through dialogue and by attempting to understand what they’re saying.

2012: The Year of the People

-          Focus on the people!

B. Metrics-Driven Ruby/Rails Performance by Jeff Casimir

On performance

-          What is “mature”?

-          If it does what you want, but does it slowly, then it’s not mature.

-          Performance = happiness = more users = profits

-          Performance is User Experience (UX). UX is the only thing that matters.

Setting Goals

-          If a page doesn’t respond within 500ms, then it’s really slow. Another person says it has to be under 100ms.

-          Metrics: If you aren’t measuring, then you’ll run into problems. So, fix your problems early.

-          If you have an application that makes money, then use New Relix to look through your software’s performance.

X-rays for Code

-          Solving Problems

o   Locate

o   Recognize

o   Solve

o   Validate

Perftools from Google

-          Every time Slice:

o   Which method is being executed?

o   Who called it?

-          wrapped up into rack middleware

o   You can install this middleware by dropping it into an initializer.

-          Perftools Text Output

o   Comes out without headers

o   Can find methods that are computationally expensive

-          PDF Output

o   Who is responsible for all the method calls? It shows it here.

-          Example: Blog Dashboard

o   Shows how much methods take up time, but are kind of difficult to parse through.

o   In one instance, removing one method improved the program efficiency by 70%.

MemProf by Joe Damato

-          Only 1.8.7 ruby compatible, but a great program.

There is a divide between guessing and knowing

-          if you don’t measure, you won’t know. Don’t guess, just know.

C. How to scale a Ruby Web Service by Jeremie Castagna – At&t interactive

How to stick with a web service in Ruby

The Problem

-          What does your typical Ruby web app look like?

o   A large footprint. Rails app takes up a lot of memory.

o   Single track mind. It can really only do one thing at a time.

o   It’s a slow communicator

o   Server usage: Ram is at 90% usage, while cpu usage is at 15%.

o   We want to reduce the amount of ram the application is taking, so we can run a lot fo requests through it.

How to fix it?

-          Reduce Memory

o   Reduce the amount of code in your app.

o   Avoid creating lots of classes. Classes take up a lot of memory in Ruby. The garbage collector doesn’t collect classes.

o   Hold on to objects as much as possible

o   Avoid singletons and monkey patches.

o   Slim down memory usage of gems

§  Use only very small gems, so probably not rails. Rails is great at creating html, but not great at the rest. So, use jsong or agile, which is a bit faster. An easy way to reduce the amount, is by using Sinatra or another rack base.

o   Profile and replace dependencies as needed.

-          Keep Ruby busy

o   Concurrency in Ruby Web Apps

§  Rainbows! Multithreading with ThreadPool

·         Multiple clients go through Rainbows! which go through multiple app threads, which then go to the backend. It takes up no extra memory J.

§  Use Ruby 1.9 for evented IO

§  Not all interpreters have a GIL

o   Compress large backend responses when possible

o   Keep connections alive to your backend

o   Use HTTP Pipelining for multiple calls

§  Basically, sending all the information it needs at once, which the backend then returns all at once.

o   Another method is Multithreaded pipeline HTTP

o   Kill Long Running Request

-          Use efficient IO

More Problems

-          Too many Rainbow connections

-          Avoid bad states by discarding timed out connections

-          Apply standard thread safety principles

D. KILL!KILL!DIE!DIE! Load Testing with a Vengeance by Dan Yoder

-          Remember how testing used to suck?

-          Load testing still sucks

INCOMPLETE NOTES ON THIS PART (sorry)

Rack Middleware

-          As it is envisioned in pep-0333 off python

-          Request Processing

o   Middleware stack is between the server and the framework

This concludes Part I. I'll posting Part II very soon. Cheers.