Tyler Wolff » Web

Fixing the Web Inspector Font In Safari

Tyler — Sun, 29 Aug 2010 21:06:37 +0000

With the release of Safari 5 came a bunch of great new features including updates to the web inspector. If you use this tool as much as I do you will have noticed that the font changed from Lucida Grande to Menlo, a larger, monospace font. This makes the web inspector looks more like the one in Chrome. A monospace font makes sense for this type of tool but I personally don’t care for it much. I would rather have the inspector show Lucida Grande again.

Luckily, I stumbled upon a fix crafted by Elliott Kember and it’s pretty slick. Here’s what you need to do:

Browse over and open /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Resources/
inspector/inspector.css with admin privileges and add these few lines to the end of the file. That’s it!

.outline-disclosure li {padding: 1px 0 1px 14px;} body.platform-mac.platform-mac-snowleopard .monospace, body.platform-mac.platform-mac-snowleopard .source-code {font-family: 'Lucida Grande', monospace;

Note: if you are still using Safari 4, edit the file at /Applications/WebKit.app/Contents/Frameworks/10.6/WebCore.framework/Versions/A/Resources/inspector/inspector.css

New INK Design Website

Tyler — Sun, 04 Jul 2010 22:31:37 +0000

During the past few days I had the chance to remake the INK Design website for my good friend Kamran Samimi, a printmaker and graphic designer from Honolulu, Hawaii. We brainstormed on a bunch of out-there ideas to present his work but eventually settled with something somewhat similar to how this site is laid out. Kamran had already been putting some of his work on a Cargo Collective site, one of the coolest web frameworks out right now, but he had reached the limit to posting as a free user and he didn’t want to pay for it since he has his own website. I thought why not take the code base from my current site and modify it to make it more project based, similar to how many cargo collective sites are. This is how it turned out:

How it was made

Just like this site, the INK Design website is powered by WordPress and the Carrington framework. WordPress handles all the content and Carrington handles how the content is put together and displayed to the user (more about Carrington in this post). Since my site already has many of the features Kamran wanted in his site like in-page ajax loading of posts I built upon what I already had, changing some CSS here and modifying some Javascript there. Getting a test site up was a fairly quick process. The good thing is, while I was creating the theming for the site, Kamran could post projects to the site simultaneously.

In-page loading of project posts

Once the site was functioning well enough I decided to give it some INK Design flavor. One of the original concepts for the site was to have one giant canvas that moved around depending on what type of projects you wanted to see and for this Kamran created a huge spaced out image of blending colors and designs to act as the background. I took this giant image and cut it up into ten smaller ones to use for the background of the site design we had created. I found a pretty nifty plug-in, jQuery Backstretch, that provided exactly what I needed to display a fixed full screen background at various screen resolution sizes. I used this to create a randomized full screen background generator. If you refresh the page or navigate to other pages you’ll see it in action. The good thing about the backstretch plug-in is that it loads up the image after the page has rendered decreasing page load time.

The one big problem in this site is that it uses a couple fixed position elements which do not work well on mobile devices like the iPad. For instance the background will scroll up on mobile safari revealing a basic gray colored background when it should remain fixed. Also, the layout gets squished together a bit more than it should on mobile browsers. Hopefully one day when I have more time I’ll be able to fix these issues.

All Tools Used

Update: this site is also featured on the Carrington framework’s homepage!

Google Font API

Tyler — Thu, 27 May 2010 10:49:06 +0000

So I ran into this little gem today while trying to fix a layout bug I was getting from custom fonts being loaded on this page after everything else was rendered. Although it did not solve the problem, Google’s font api is a pretty handy tool for anyone using web fonts. What it provides is a simple API that helps you add web fonts to web pages without all the fuss of the @font-face tag. It also provides access to a some popular web fonts out there like Droid Sans, served right from google servers. Sounds pretty cool eh? Here’s a simple example of how to enable a web font like Droid Sans into your webpage.

1. Add this above your other linked css documents in the of your html document:

2. Declare the embedded font anywhere in your css like so, and your good to go:

h1 { font-family: 'Droid Sans', arial, serif; }

It’s that easy! and theres more… Google and Typekit worked together to create a Javascript library for loading fonts with even more control over everything called WebFont Loader. What’s cool about this library is the ability to use multiple web-font providers like google, Typekit, or your own custom one. Another big plus of using this library is a way to control font styles before and after the actual font is loaded, which means your site’s text can be made visible quicker as the fonts load. After reading about this more, it might prove to be useful in solving the problem I was having with the layout rendering on this page.

Check it all out:

Google Font Api »
Google Font Directory »
WebFont Loader »

Some Fresh New Web Tools

Tyler — Wed, 05 May 2010 01:19:49 +0000

Here’s a listing of some really cool web development tools I’ve come across in the past month or so. Some of these tools are old while some are new, but they are all very useful. If you are a web developer I suggest checking all of them out.

Adobe Browser Lab – browserlab.adobe.com

I’ve previously used other services like http://browsershots.org/ to check browser compatibility but nothing even comes close to being as simple as Adobe Browser Lab is. It’s extremely quick and makes it almost trivial to test out different browsers for any website you are working on. For mac users that don’t have a vm running windows this tool is perfect for checking IE. One great feature is the ‘Onion Skin’ view where the page renderings for two different browsers are overlaid on each other, allowing you to see even the slightest pixel differences. The one flaw of this tool is that it only includes versions of the most popular browsers (Chrome, Firefox, IE, Safari), so if you need to test out other browsers like Opera you need to do so some other way. Either way, this tool is definitely worth checking out.

0to255 – 0to255.com

My friend Arthur told me about this simple color tool a few weeks ago and since then I have found myself using it all the time. What it does is map out light to dark variations of a single input color based on hex value. Sounds pretty basic but it turns out to be really useful when you have some colors in mind already and want to try using some slightly different ones. The site is fast and simple (clicking on a color automatically copies the code to your clipboard), plus it looks really slick. I’ve tried using other color tools like Adobe’s Kuler but they never wound up being as useful as this one did.

iPad Peek – ipadpeek.com

This doesn’t actually render a site like the real mobile safari does on the iPad, but it’s still pretty good. If you need to do some quick iPad rendering tests this tool will do the job just fine. From what I can tell it does some things like a real iPad, such as adjusting to your sites width, but it still doesn’t render an iPad specific site correctly, like Sproutcore’s hedwig example app below.

CSSDesk – cssdesk.com

I’m not sure if I would ever use this but I had to include it because it’s a really slick looking tool. Made with HTML5, CSSDesk is a live updating development environment for html/css snippets. If you want to try out some code fast to see what it will look like, this tool is made for you. You can turn code highlighting off and on, change the background, download the code you’ve developed, and even share it.

Typetester – typetester.org

If your into testing out what different fonts look like in a browser then this tool is key. Typetester lets you try out all sorts of fonts (mac / windows / both) to see how they render within your browser. What’s nice is that you have 3 separate areas to compare fonts and other type options. For instance, the screenshot below shows renderings of Verdana, Trebuchet MS, and Arial from left to right, all set at a size of 1.2em. There are many more options available on the site and when you find a configuration you like, just download load the CSS for it. It’s simple.

Another type tool worth checking out is this Web Font Specimen that allows you to test any font you want on a pre-made html type specimen page. The good thing about this is that once downloaded, you can test out any font you want easily, including those imported via the @font-face tag.

Nav-o-matic – labs.engageinteractive.co.uk/nav-o-matic

Nav-o-matic creates the markup and css needed to create a navigation menu based on an image sprite for normal, hover, and active states. All you have to do is upload your menu image, mark the vertical boundaries of each button, and bam, beautiful css is produced automatically for you within a matter of seconds. I just found out about this but I wish I had known about it long ago. Creating the css to do this is not hard, but nav-0-matic makes it far to easy to do it any other way. Definitely go check this out if your making a sprite based navigation menu.

New Project: BraxtonsDiary.com

Tyler — Mon, 08 Mar 2010 01:36:52 +0000

I just finished setting up a photo / music journal site for my friend Braxton Olita. Check out the site, or learn more on the projects page.

24 ways: Make Your Mockup in Markup

Tyler — Tue, 23 Feb 2010 02:06:11 +0000

There are many arguments for mocking up a website in html rather than doing so beforehand in photoshop, but I personally have never considered the method viable, at least for myself. It always seemed like it would waste a lot of time since I tend to go through a whole bunch of different mock ups before the final is marked up. However, after working on a site where I did most of the designing in markup and after reading the article below from 24ways, I’ve realized that it could be more productive in some cases to ditch photoshop, and just mock up a website in markup.

Check out the article: 24 ways: Make Your Mockup in Markup.

I really like the point the author makes about using RGBA to set all the background colors, thus making it extremely easy to change the whole color scheme of the page instantly. That could save a ton of time.

The New Website

Tyler — Wed, 17 Feb 2010 08:08:58 +0000

I have been wanting to update my website for a long time, but with school, work, and everything else on my plate last semester I could not find the time to really make it happen. Fast-forward to the start of 2010 and I have graduated, plus I have had more time on my hands to actually work on fun things, like a new website. I already had a ton of ideas for how I wanted the site to be, so I started designing / coding what eventually turned into the current version of this website.

The Concept

The basic concept I started with was to have a home page that would show small excerpts of blog posts with a corresponding thumbnail. Upon clicking one of these excerpts, the full post would then be loaded inline via ajax. In addition, I wanted to have everything align to a grid at all times. Before making this site I had seen this done on a couple of sites, but none of these were running on WordPress.

The Main Problem

With WordPress you normally have one template for your homepage and one for a single atomic post which means that a single post on its own can only be loaded via the single template. Because of this a post only exists on the homepage, where all posts are normally shown, and on its single, or permalinked page. There is no way to grab an atomic post on its own using WordPress’s default functionality. To get the layout I described above I could have made the single post template only return the post’s content and have that load through ajax via its permalink. However, the problem with that is when a user navigates to a permalinked post, all that would show up would be the content of the post. What I needed was a way to grab a post’s content on its own while also providing a nicely styled single page for permalinked posts.

How I Did it

I realized that I would have to write custom functions to query the wordpress database in order to do this, and so I started with that. Then one day I stumbled across the Carrington, a CMS theme framework that extends WordPress and makes it extremely easy to customize. The main difference between WordPress and Carrington is in how the code is abstracted and what can be done with those abstractions. Here is a diagram that shows the difference between the page load for a single post view in the WordPress Default theme and how the same in done in Carrington:

Now all this is great for customization, but why I eventually settled with using the Carrington Framework was because of the built in Ajax loading. It was exactly the thing I needed for this site as it gave me a way to show both excerpts and full posts on the homepage, while also providing a template for permalinked posts. Plus, its slick. Carrington provides it for viewing archives, but it’s easy to apply it to all posts.

Another wonderful resource I found for use on this site was jQuery Masonry, a layout plugin that auto-aligns elements based on a given grid. I’ve always loved sites that auto-align elements of different sizes so I was happy to apply that same look to this site. I had to hack the initialization part of the plugin a bit to get it to work right with Carrington right but it turned out to work great! I love this plugin.

Technology Used

Overall, I am very satisfied with how the new version of tylerwolff.com turned out, though there are still problems to be fixed (IE7 layout, contact form messages, etc). In the future I plan to repair these problems, as well as add more content to the entire website. I might even write some more entries on the making of this site, going through some of the custom code I had to write to get everything to work together. What’s cool is the site is now featured on the Carrington homepage and showcase page. Check it out ↓

Hello HTML5

Tyler — Wed, 16 Sep 2009 06:13:02 +0000

HTML 5 Experiment from 9elements.com

Due Dates 2.0 (the Web Application!) is born

Tyler — Mon, 08 Dec 2008 11:33:00 +0000

Developing the Due Dates 2.0 web application was an experience that really summed up everything I have learned about software engineering in the last 5 months. I worked alongside Aric West and Mari-Lee Flestado, as team UlaUla (red) in creating this application. In developing Due Dates 2.0 I used all the tools available to me including quality assurance tools, JUnit, configuration management, continuous integration, software ICU statistics, Google Project Hosting, Wicket, and of course Java. Creating the system was to say the least a very rewarding challenge. I think our overall project turned out nicely. DueDates-ulaula Homepage.

screenshot of the login page

NEW FEATURES OF DUE DATES 2.0

The main new feature of Due Dates version 2.o is that is a legit web application, created through Wicket. The other features include a login in page that verifies users from an XML file, a result page that dynamically updates, sorts, and filters your borrowed items, and an alerts page that can schedule email notifications when items are due soon. Its a pretty cool system that is also makes use of CSS, so it looks good to the user. Our group was able to implement all of these features into the system. However, we did not add any extra functionalities to the application.

TEAM DEVELOPMENT

I really enjoyed being a part of a three-person development team. I found that overall, more was getting done with three people always working, rather than just one or two. In the past I’ve gone weeks without having to do an svn update, but with this project I was constantly updating and committing code. I liked the fact that whenever I went to work on Due Dates, there was usually some new code for me to check out. It was a much more efficient system working together than I’ve experienced in the past.

Communication was a big plus for our team. We all met a few times a week to do some planning, reporting, and programming. Right off the bat we decided what everyone on the team was going to more or less do, and we got on it. We delegated tasks to everyone through Google project hosting’s issue manager. To see what tasks I worked on, view my issue log. One of the main things I enjoyed about working on Due Dates 2.0 was the fact that there were a bunch of different and unique things to do. I personally was excited to work on the CSS styles for the web app, as well as creating the XML configuration manager, since we’ve never done that sort of thing before. Everyone was able to bring their own skills together for this project and it worked nicely.

When we weren’t meeting in person, we were meeting online, talking via instant messages. I did this a lot with the other team members and it worked really well for throwing bugged code back and forth. However, meeting in person was definitely needed for a project like this and it really helped our overall system develop. I remember on the first day we met as a team, Aric had a great idea of planning out exactly what general classes and methods we were going to have so we could all work on things even if something the code relied on was not implemented yet. This worked well when creating the Wicket classes for instance.

DEVELOPMENT PROCESS

If I could sum up the development process of Due Dates in one word I would say it was ‘smooth.’ For most of the time spent on development, I did not feel stressed at all. This was partly because I was working regularly, as were my teammates. Since we were committing often, we did not have much that was left to do last minute.

DEVELOPMENT PROBLEMS

The most frustrating and challenging problem I had during the entire development process happened the night before Due Dates 2.0 was set to be finished. I had been working on the overall test suite for the system and I got stuck on testing the ResultPage class which displays a users borrowed items to screen. In testing the class, I was simply trying to update the page with some borrowed items that the test user had. It is a simple test to run manually through the web interface, and it works every time no matter what. However, when running it in a test case, it would never work. The dataview was never created. I consulted my teammates about this, as well as other students and nobody could figure it out. I spent most of my night trying to debug this simple test and wasn’t able to figure it out. However, in trying to fix it, I came upon several other possible bugs in the system.

I attribute most of the churn on the last night to this bug, as I re-coded a lot of things in hope that it would fix.

Other than this bug, I didn’t run into a lot of problems over the last two weeks. Our group process ran smoothly and we only had minor problems which were fixed quickly. The only thing worth mentioning was the first time I got an update conflict on SVN. This was my first time dealing with a conflict and it really confused me. I didn’t know what was what, but eventually I figured it out and it was no problem after that.

SOFTWARE ICU STATISTICS

The overall status of our project reflects in our HackyStat statistics, which are nearly all in the green:

Our development time as a group was consistent, and our commits, builds, and tests were also consistent. Our coverage trend was always going up and we ended with 96% method coverage. The only thing that got messed up was the churn, which was great until the last night (when I was trying to figure out the test bug). However, the overall churn trend is more or less consistently low.

Our development trends were somewhat accurate in representing each members participation.

development time graph

As it shows here, I have the least amount of development time of everyone in the group and Mari has the most. Aric is right in the middle. Everyone seems to have worked nearly every day during this project which is good. What is flawed in this graph is the time spent out of eclipse. This includes working on wikis and for me especially, working in dreamweaver. In addition, when looking at other trends the data seems to change:

commit data

Here it shows that I have the most commits while Mari has the least. Aric’s right there in the middle again. This is true of system builds as well:

build data

Surprisingly though, Aric and Mari ended up with the exact same amount of builds. I thought that was pretty cool.

It was good having the Software ICU monitoring our group process and system health. I can see a real change in how I work on stuff now compared to 5 months ago. I like to work regularly instead of working just a day here and a day there.

FINAL THOUGHTS

As a software developer I would like to continue creating things in the same way I have with Due Dates 2.0. All the software engineering tools available really aid in creating robust systems. If only I had known about SVN or JUnit before, my code would have been better. Overall, I think creating this web application shows how I have grown as a software engineer. I would not have been able to do such a thing before. Although there are many, many things that can be improved on our version 2.0, I think it turned out quite well for the time we had. I hope to add to it one day.

My first Wicket Web Application

Tyler — Mon, 24 Nov 2008 06:32:00 +0000

There are many frameworks available today for creating dynamic web applications, some of which are extremely complicated and hard to use. Wicket is one of the few, easy to use tools out there that works well with Java programming. What makes Wicket different from most other web application tools is that it effectively separates the logic of the actual program from the simple HTML markup of a web page.

This week I set out to learn how to use Wicket in order to create a small web application for a simple stack Java program. With this program, a user can push items onto a stack, pop items from a stack, as well as clear the entire stack. Although the functionality of the program was quite simple, creating a web application for it did turn out to be more of a challenge.

Final Distribution Package for the Web App: stack-wicket-wolfft-1.0.1123.zip

final view of the stack web application

THE DEVELOPMENT PROCESS:

After reading some of the chapters of Wicket in Action as well as reviewing some actual examples provided by Dr. Johnson, I started to grasp some of the basic principles of using Wicket. To my surprise creating an HTML page to interface a Java program is an extremely easy and clean process. Since there is no logic in the markup, the HTML page is left as simple as possible, and can be stylized and viewed all on its own.

On the other hand, creating a Java application that works with this HTML page is a bit more complicated. I wanted to create a stack application that would employ the use of forms, basic text output, as well as table output. In addition, I wanted to give each user of the application their own session in order to store their personal stack object and data. Luckily with Wicket, this task was not too daunting either.

To do it all, I had to create an application class, then a page class, and then finally a sessions class. All of these components essentially run together to create the stack web application. Creating the page class was probably the most challenging out of all the classes since all sorts of different HTML elements were being updated on the one page at once.

Another thing worth mentioning is the applications use of Jetty, a web server implementation that enables Java applications to run on a server. This was used to create a fully-working web application, though I more or less just reused code to get it to run.

DEVELOPMENT PROBLEMS:

I had a good time creating this stack application. I get real satisfaction from creating something that anyone can go out and use without having to run through a console. However, I did run into some small problems while developing it all. For one I had to figure out how to alert the user when they were trying to pop an empty stack. I fixed this by creating an error response text field in the page that would alert the user if they were popping an empty stack. Something else I could have done with this was only make the pop button visible when there were items in the stack.

Something else that I ran into was that initially the stack was presented in the table in list form, not stack form. This means the first item pushed was always the top item in the table. The way I like to thing of stack is the opposite of this and I wanted to make that clear on the page. I ended up creating a method in the Stack class that would put the stack in the right visual order right before updating the data to to table. It worked out quite nicely.

Also, one of the funny errors I kept getting was from CheckStyle on the basic Stack package classes. It simply stated:

Got an exception - java.lang.RuntimeException: Unable to get class information for @throws tag 'EmptyStackException'.

This was extremely confusing because I did not even alter the classes that the error was from. I was really stumped with this one and searched all over to try and figure it out. The problem ended up stemming from the build.xml file, which was not compiling all the classes, namely the EmptyStackException class. It was something small that I missed and when it was fixed it all worked nicely together.

LESSONS LEARNED

Creating this simple web app was more challenging than I initially anticipated. I spent a lot of time looking at the Wicket examples, trying to figure out the best way to create the application page, and still it wasn’t working for me. Yet, now that it is all done, I feel I have a fairly good understanding of the Wicket framework. All the work spent on figuring out different ways to do things resulted in more knowledge of how things work. I do feel comfortable with Wicket and I know I will be using it in the future to create even more extensive web applications.