Tech Roots » CSS/HTML/JavaScript http://blogs.ancestry.com/techroots Ancestry.com Tech Roots Blogs Tue, 22 Apr 2014 23:35:02 +0000 en-US hourly 1 http://wordpress.org/?v=3.5.2 Utah Code Camp 2014 – A Success for Ancestry.com Tech Team and Whole Communityhttp://blogs.ancestry.com/techroots/utah-code-camp-2014-a-success-for-ancestry-and-the-whole-community/ http://blogs.ancestry.com/techroots/utah-code-camp-2014-a-success-for-ancestry-and-the-whole-community/#comments Thu, 20 Mar 2014 18:27:12 +0000 Mitchell Harris http://blogs.ancestry.com/techroots/?p=2099 Utah Code Camp 2014 came and went this weekend. More than 850 people attended and with more than 70 sessions, it was the largest code camp in Utah history. Thanks to Pat, Craig, Nate, and Kerry  of Utah Geek Events for putting it all on. Ancestry.com participated in a pretty big way. In addition to the… Read more

The post Utah Code Camp 2014 – A Success for Ancestry.com Tech Team and Whole Community appeared first on Tech Roots.

]]>
Utah Code Camp 2014 came and went this weekend. More than 850 people attended and with more than 70 sessions, it was the largest code camp in Utah history. Thanks to Pat, Craig, Nate, and Kerry  of Utah Geek Events for putting it all on.

Ancestry.com participated in a pretty big way. In addition to the many Ancestry.com employees in attendance, we had three speak.  Bressain Dinkelman presented a session titled, “Yes, You Belong Here,” about the Imposter Syndrome in the tech world, and how to overcome it. Craig Peterson presented a session titled, “High Performance Web Services with Apache Thrift.” I presented a session called, “Making Your Own Domain Specific Language,” and also was called in last minute pinch to  hit speak on RavenDB for a presenter that got pneumonia.

WP_20140320_001

 

In addition to employees attending and speaking at the event, Ancestry.com also sponsored the event. Did you find our spot next to the elevators on the first floor? We were handing out T-Shirts, hand sanitizer, pens, candy, and evangelizing how great it is to work here.  We’re proud to be a sponsors to of Utah Code Camp, and hope for another great camp next year.

The post Utah Code Camp 2014 – A Success for Ancestry.com Tech Team and Whole Community appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/utah-code-camp-2014-a-success-for-ancestry-and-the-whole-community/feed/ 0
Video Q&A with Lead Engineer at Ancestry.comhttp://blogs.ancestry.com/techroots/video-qa-with-lead-engineer-at-ancestry-com/ http://blogs.ancestry.com/techroots/video-qa-with-lead-engineer-at-ancestry-com/#comments Fri, 21 Feb 2014 01:14:53 +0000 Melissa Garrett http://blogs.ancestry.com/techroots/?p=1974 Jeremy Pollack, a lead engineer at Ancestry.com, answers questions on the technical backend of AncestryDNA in a video interview with InfoQ. The interview took place after his presentation with Bill Yetman on scaling AncestryDNA using Hadoop and HBase at QConSF in 2013. Check it out!

The post Video Q&A with Lead Engineer at Ancestry.com appeared first on Tech Roots.

]]>
Jeremy Pollack, a lead engineer at Ancestry.com, answers questions on the technical backend of AncestryDNA in a video interview with InfoQ. The interview took place after his presentation with Bill Yetman on scaling AncestryDNA using Hadoop and HBase at QConSF in 2013. Check it out!

Jeremy P

The post Video Q&A with Lead Engineer at Ancestry.com appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/video-qa-with-lead-engineer-at-ancestry-com/feed/ 0
Creating a Completely Accessible Navigation Bar in HTML, CSS, and JShttp://blogs.ancestry.com/techroots/creating-a-completely-accessible-navigation-bar-in-html-css-and-js/ http://blogs.ancestry.com/techroots/creating-a-completely-accessible-navigation-bar-in-html-css-and-js/#comments Mon, 27 Jan 2014 10:30:20 +0000 Jason Boyer http://blogs.ancestry.com/techroots/?p=1859 Recently, I volunteered to prototype a new global navigation bar for the core Ancestry.com website. This was a huge opportunity for some drastically needed improvements, not only for the code behind the header, but more importantly, the accessibility of the navigational items. Even though we’re early on in this process of creating an accessible navigation… Read more

The post Creating a Completely Accessible Navigation Bar in HTML, CSS, and JS appeared first on Tech Roots.

]]>
Recently, I volunteered to prototype a new global navigation bar for the core Ancestry.com website. This was a huge opportunity for some drastically needed improvements, not only for the code behind the header, but more importantly, the accessibility of the navigational items. Even though we’re early on in this process of creating an accessible navigation bar in HTML, CSS, and JS, I wanted to share some of our goals and challenges and gather any additional insight others may have to offer.


True or False?
Accessibility is only relevant to projects designed for the blind.


False! So false. This is actually one of the most common misconceptions that I’ve come across with new web developers. Accessibility means ensuring that all users are able to experience your product in a way that works for them.

The main navigation bar on a website is one of the most important areas that needs to be accessible. If users can’t navigate your site, guess what – they are not going to use it! In order to cater to your users, you have to know who your users are. Our users at Ancestry.com vary greatly by age and technical skill. After digesting our user stats, we focused in on four key areas of accessibility:

  1. Keyboard accessible navigation – Keyboard accessible navigation is crazy helpful for people with dexterity issues. Moving and clicking a mouse on a tiny 16×16 pixel icon can prove to be very difficult. This also helps our power users that want to improve their workflow by navigating with access keys.
  2. Touch device capable – More and more of our users visit the site through touch enabled devices, including phones, tablets, and even desktop computers. Unbeknownst to many developers though, if you have dropdown menus that are triggered by hovering over an anchor element, many users will never be able to access those secondary menu items.
  3. Mobile users with smaller screens – Given that most mobile devices are touch-enabled, this is still a different group of people due to the screen resolution. A surprising amount of our users (growing daily) are now navigating on devices with screens smaller than 768 pixels wide.
  4. Assistive technology friendly – Users with sight disabilities rely on screen readers and other assistive technologies. We strive to keep this in mind when building pages, but honestly, our current support of assistive technologies is quite low. We’d love to improve this effort, starting with this new header.

Of course there are other reasons for updating our current header (such as code cleanup, standardizing styles, performance improvements, easier access to most visited pages, better use of screen width, and overall simplification), but I’m going to focus on how we’re trying to improve the four points above.

Before we dive into the details for each of the four areas, take a look at the two different variations:


Keyboard Accessible Navigation

If you try to navigate the current Ancestry.com header through key presses, you’ll quickly notice that you cannot access the submenus, which contain some of our most visited links. This newer version had to fix this.

Task #1 was to make sure that someone could use the “tab” key to make it through the entire list of navigation links. Initially, this wasn’t all that difficult. I only had to make sure the markup was semantic, in the correct order, and no autofocusing-elements on page load. Then, thankfully, most web browsers do a decent job taking you from one link to the next.

The challenge came when we added in the drop down menus. They are handled by a global “callout” widget that moves the contents of the callout into a new element that is a direct child of the element. This is done to avoid any possibility of z-indexing issues that we had dealt with previously. However, in this case, it complicated the task of being able to tab to each navigational link since the DOM structure is changed when the callout opens. We got around this by adding custom keyup events detecting the arrow and bracket keys. This actually created an additional benefit of being able to more quickly focus on the link that you needed (instead of pushing tab fifteen times, you can now push it four times and then push the down arrow once). So even though our goal was to be able to tab all the way through, we feel the solution we’ve found with the arrow or bracket keys is even better.

Task #2 was to make it even easier to jump to the most used pages (such as a user’s tree, Search, DNA, etc.) through the use of access keys. Web access keys are shortcut keys to certain pages or parts of a page.

The challenge with access keys is that all software programs like shortcut keys! This causes lots and lots of potential conflicts. The best recommendation for access keys that I’ve found was from the UK government, albeit over 11 years old. On a side note, here is an awesome read about access keys and keyboard accessibility article by WebAim.

Other than the letter “S” for skipping navigation, they recommend using numbers for your main links. Our main links are different than theirs, so this represents our current implementation on the new header:

  • alt + s   Skip navigation
  • alt + 1   Home
  • alt + 2   User’s tree
  • alt + 3   Search
  • alt + 4   DNA
  • alt + 5   Resources
  • alt + 6   Shop
  • alt + 7   Quick Lookup
  • alt + 8   Messages
  • alt + 9   Hints
  • alt + 0   Account

In order to make our users aware that these access keys exist, we would simply put a hidden link at the end of the page that is shown on focus. Users who navigate with the keyboard would be able to find our access key definitions page.


Touch Device Capable

If you visited our site a year ago on an Android or Windows touch device, you could not access the submenus in the main navigation bar. Those devices trigger the hover and click event at the same time, rendering submenus shown by hover as completely useless. The hover would occur, instantly followed by the click, which closed the hover dropdown, and then proceeded to the clicked link. A simplified version of the markup was like the following:

<div class="linkWithDropdown">
	<a href="/a/"">Place A</a>
	<ul class="dropdown">
		<li><a href="/b/">Place B</a></li>
		<li><a href="/c/">Place C</a></li>
		<li><a href="/d/">Place D</a></li>
	</ul>
</div>

And the relevant CSS like so:

.dropdown { display:none; }
.linkWithDropdown:hover .dropdown { display:block; }

iOS devices did not have the same issue as they required a tap to trigger the hover (which opened the menu) and another tap to trigger the click event. This behavior was actually fortunate for this current scenario but causes issue in other use cases.

Our fix for this case was to remove all CSS hover styles applied to those elements on touch-enabled devices. This made the first finger tap on all devices trigger the click event. We then stopped the event from changing the page, stored a flag marking that it was open, and then listened for the next finger tap. On the second finger tap, it would then fire the click event again and allow you to go to that page. Basically, we disabled the iOS device tap behavior, made it consistent with Android, then added custom code to mimic the disable iOS behavior, but in a cross-device-compatible-sort-of-way.


Mobile Users with Smaller Screens

Ancestry.com was first built as a desktop experience, assuming a browser with a screen width of 1024 pixels. This was true for the large majority of our users 10 years ago, but is far from accurate today as more and more people are visiting our site from mobile devices. These smaller devices, such as the iPhone, are capable of rendering a desktop experience on their tiny little screen, but result in a far from optimal experience. Enter responsive web design (RWD).

The main goal of RWD is to display the same information to a user, no matter what device they’re on, in the easiest to use format possible. When it comes to navigation, it’s a poor experience to try and click on a tiny, zoomed-out, 10×8 pixel link to get to a page. In my opinion, (formed from many others’ research) links on touch devices should never be smaller than 44×44 pixels. This makes clickable areas much easier to tap. RWD has now been a hot priority at Ancestry.com for well over a year now. We’ve made huge leaps forward, and this new header is no exception. It is fully responsive, meaning it has a fluid layout and adapts its visual layout according to the screen width that is available to it.


Assistive Technology Friendly

This category covers those who use screen readers, screen magnifiers, and other assistive software. Even though this is currently a miniscule amount of our users, I see it as a high priority item. I come from an educational background, where the fact that all people deserve an equal right to learn was engrained into me. The desire to meet this goal has transitioned nicely to the frontend web development role that I’m now in to help all people access the content that a website delivers.

Semantic HTML5 markup is now used to assist in proper categorization of DOM elements. The new header uses the <nav> element as its outer wrapper, <a> elements only when changing a URL, and <button> elements for performing javascript actions. Here is the basic markup of the new header:

<nav class="nav" id="nav">
	<a accesskey="2" href="/tree/boyer/">Boyer Family Tree</a>
	<ul class="navSubMenu" id="navTrees">
		<li><a href="/tree/boyer/">Boyer Family Tree</a></li>
		<li><a href="/tree/nielson/">Nielson REAL Family Tree</a></li>
		<li><a href="/tree/start/">Start a tree</a></li>
	</ul>
	<a accesskey="3" href="/search/" id="navSearchTrigger">Search</a>
	<ul class="navSubMenu" id="navSearch">
		<li><a href="/search/">Search All Records</a></li>
		<li><a href="/search/census/">Census & Voter Lists</a></li>
		<li><a href="/search/birth/">Birth, Marriage & Death</a></li>
	</ul>
</nav>

Top-level links are direct children of the <nav> element. Submenus are visually hidden by default, but still available to be read by screen readers. Many callout and tab plugins hide content with CSS via the display property. This can be bad for accessibility as there may not be a way for people using screen readers to find that hidden information. That’s why, rather than setting the display property on those submenu <ul> elements, we use the following CSS:

.navSubMenu,
.screenReaderText  { height:1px; line-height:2em; margin:-1px; opacity:0; overflow:hidden; pointer-events:none; position:absolute; width:1px; }

Another best practice is to provide users a way to skip the navigation. This is done by placing this HTML as the first item in the <nav> element:
Skip Ancestry.com navigation

Our header is included in a lot of different locations, following several different page layout patterns. We cannot assume that our main content is wrapped by an element with the ID of “skipped-nav,” so we add one directly after the main <nav> element. It’d be better to just wrap your main content with a unique ID, but that wasn’t a plausible solution for us. Relevant HTML:

<div id="skipped-nav"></div>

Keep in mind that there are some issues with “skip to content” links in Chrome and Internet Explorer, causing it to fail to focus on the “skipped-nav” element after the navigation. There is a JS workaround for this issue shown in the demo (go here and search for the function “fixSkipLink”).

We have learned a lot during this effort and feel we are getting closer to releasing this responsive, accessible, awesome, new global navigation bar, but we are still very much open for feedback. Since we built it as a Google Chrome plugin – you can try it yourself. If you’re not in Chrome, open it. If you’re in IE, I’m sorry.

Become a power-user and try only using your keyboard to navigate. I think alt+7 will be a favorite shortcut for a lot of users. Please keep in mind that the plugin is a prototype, so there are some bugs in it. Once you’ve played with it for a while, please complete this super short survey to let us know what you think. Since we’re involving users and others early on in the process, we are still very open to suggestions.

The post Creating a Completely Accessible Navigation Bar in HTML, CSS, and JS appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/creating-a-completely-accessible-navigation-bar-in-html-css-and-js/feed/ 0
API Performance Monitorhttp://blogs.ancestry.com/techroots/performance-and-stability-dashboard/ http://blogs.ancestry.com/techroots/performance-and-stability-dashboard/#comments Wed, 15 Jan 2014 07:00:37 +0000 Anders http://blogs.ancestry.com/techroots/?p=1415 My team has been tasked with providing a dashboard for some of our product teams that enables them to aggregate various monitoring systems, logs, metrics, and other forensic tools into one place. While provisioning this dashboard, we discovered we needed a tool that could hit an endpoint, run code against the response, record the results, and… Read more

The post API Performance Monitor appeared first on Tech Roots.

]]>
My team has been tasked with providing a dashboard for some of our product teams that enables them to aggregate various monitoring systems, logs, metrics, and other forensic tools into one place.

While provisioning this dashboard, we discovered we needed a tool that could hit an endpoint, run code against the response, record the results, and do it all on a scheduled basis.

I was assigned to build this tool, which, thanks to modern technologies, only took a couple of days and is now a simple, lightweight node.js server.

One passes in a request object (with the url, method, headers, url parameters, etc.), an interval (e.g. 30000 ms), and a script to run against the response.  The server schedules the task with the interval given, performs the request, compiles and runs the script against the response, and records the results in SQL Server.

We inserted a dozen or so scheduled tasks, and it has been executing flawlessly for the last two weeks.

For example, here is a graph of the response time of one of our servers over the last hour:

Image 2

At some point, a response time of over 800 ms was recorded.  Sometimes a request can just take a long time and there can be a lot of reasons for it – but if it only happened once, it’s usually not worth taking the time to triage.  It is, however, at least worth checking to see if it did only happen once, so here’s a full week:

Image 3

There are spikes of ~150ms, but nothing anywhere close to a full second. It appears to be an isolated incident, so we’ll chalk it up to gremlins and move on.

With this tool available to us, it’s simple to track response times, uptime, downtime, errors, and anything else we deem interesting.

Tools like these save us a lot of time by keeping an eye on things while we’re busy with other priorities, freeing us up to work on adding new features, polishing existing functionality, and removing bugs from the code base.

The post API Performance Monitor appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/performance-and-stability-dashboard/feed/ 1
Open Source Developmenthttp://blogs.ancestry.com/techroots/open-source-development/ http://blogs.ancestry.com/techroots/open-source-development/#comments Tue, 26 Nov 2013 09:27:23 +0000 Liam Molloy http://blogs.ancestry.com/techroots/?p=1568 At Ancestry.com, we have many developers whom contribute to open source projects. Today I want to talk about an open source project I have been involved in, along with one of my team members Shane Burke. As contributing to open source projects is not directly related to the day to day development work at Ancestry,… Read more

The post Open Source Development appeared first on Tech Roots.

]]>
At Ancestry.com, we have many developers whom contribute to open source projects. Today I want to talk about an open source project I have been involved in, along with one of my team members Shane Burke. As contributing to open source projects is not directly related to the day to day development work at Ancestry, it provides an opportunity to give back to the community and allows developers to think outside the box, as well as contribute to something they are passionate about. Both Shane and I work on this project in our spare time.

FooBar football is an opensource collectable card game (CCG) based upon football. It is inspired by Magic The Gathering, Football Manager, FIFA Ultimate team, Match Atax and a host of other games.

Over the next few months, I plan to write a series on what the game is and how it is being implemented. Here is a quick overview:

  • GitHub used for version control
  • AppHarbor used for hosting
  • C# used for match engine development
  • Angular JS used for client development

GitHub

For version control, we use GitHub. GitHub is a web-based hosting service for software development projects that use the Git revision control system. GitHub offers free accounts for open source projects. In our day-to-day environment Shane and I use Microsoft’s team foundation server for version control so contributing to this project has allowed us to learn something new.

You can check out the current state of the project on our GitHub page:

FooBar football project on GitHub.

FooBar football project on GitHub.

Player card screen

Player card screen

Move simulator screen

Move simulator screen

 

The post Open Source Development appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/open-source-development/feed/ 0
CSS Woeshttp://blogs.ancestry.com/techroots/css-woes/ http://blogs.ancestry.com/techroots/css-woes/#comments Tue, 20 Aug 2013 08:00:03 +0000 Anders http://blogs.ancestry.com/techroots/?p=979 I’m not a Front End Developer, but I often find myself writing, tweaking and adjusting style-sheets to make a particular element look just right, fix layout bugs and deal with cross-browser issues. Most often I will find someone else that has already done what I want to do and look at how they’ve styled a given… Read more

The post CSS Woes appeared first on Tech Roots.

]]>
I’m not a Front End Developer, but I often find myself writing, tweaking and adjusting style-sheets to make a particular element look just right, fix layout bugs and deal with cross-browser issues.

Most often I will find someone else that has already done what I want to do and look at how they’ve styled a given element.

This is hard because for any given element there are hundreds of computed styles, so finding the crucial style differences between the element I’m styling and the element I want it to look like, is a little like finding a needle in a haystack (particularly for someone who isn’t a CSS wizard).

Thus, I wrote a tool to point out the differences for me: http://elementcomparer.aws.af.cm/

As an [overly-obvious] example, if I was working on the front page of Ancestry.com, and couldn’t figure out how to make a couple of buttons look the same, I would click on:

Image 004

And then click on:

Image 005

And inspect the differences:

Image 006

In this case, I can tell that I just need to add a few classes to the first element, let’s try ‘orange’ and ‘lrg’:

Image 007

Problem solved. I wish it was always as easy as just adjusting a couple of classes…

Clearly, this is a contrived example, but I use it all the time for more complex styling issues, and I’ve passed the tool along to my front-end developer friends here. I can only imagine the complex CSS styling issues they have to deal with.

There are likely bugs and browsers the tool doesn’t work in yet, but please give it a try and leave some feedback below.

The post CSS Woes appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/css-woes/feed/ 0
Hiring: First Test Then Assesshttp://blogs.ancestry.com/techroots/test-then-assess/ http://blogs.ancestry.com/techroots/test-then-assess/#comments Thu, 25 Jul 2013 19:50:54 +0000 Jeff Lord http://blogs.ancestry.com/techroots/?p=927 Hiring awesome people who are also talented developers is often times easier said than done. Having grown tired of sifting through endless resumes and conducting countless mind numbing interviews with unqualified applicants, our team has uncovered the filtering power of a FED (front-end development) specific assessment test. While some like to schedule time during the… Read more

The post Hiring: First Test Then Assess appeared first on Tech Roots.

]]>
Hiring awesome people who are also talented developers is often times easier said than done. Having grown tired of sifting through endless resumes and conducting countless mind numbing interviews with unqualified applicants, our team has uncovered the filtering power of a FED (front-end development) specific assessment test. While some like to schedule time during the onsite interview to complete coding tests, it’s worked best for us to email our assessment to potential candidates and allow them to complete and return it on their own time frame before scheduling an interview. This helps avoid wasting everyone’s time by bringing in people who aren’t qualified to handle the technical requirements of the position.

Our assessment test provides candidates with a layered .PSD (PhotoShop) file, as well as a simple list of requirements to consider:

  • Pixel-perfect quality level (Mac and Windows)
  • All text to be real text
  • Optimize page and improve performance where possible
  • No inline styles unless absolutely necessary
  • All containers must be vertically expandable
  • Cross browser compatibility
  • Utilize latest technologies (CSS3, HTML5, responsive design, etc.)

pixel_perfect

An experienced developer should be able to code the page in a few hours, which is enough of a time commitment to filter out those that aren’t truly interested in the job. The page also contains a wide variety of front-end challenges including a modal overlay, a form, multiple images, customized buttons, unordered lists, and overlapping elements. We can compare the code structure, CSS styling, and choice of JavaScript frameworks used in meeting the assessment’s requirements, which allows us to evaluate each candidate on a level playing field prior to scheduling an interview. We can also look at how they optimized their code to consider performance, requests, and load time of the page.

Our team reviews the tests and gives each assessment an overall rating from 1 to 10, with candidates scoring a 7 or better being considered worthy of an interview. That way, we’re only meeting with the best of the best and can more easily make a decision on who would be the best fit for the position and team. In addition, the assessment serves as a talking point during the interview, allowing the candidates to walk us through their thought process and providing us a chance to ask questions and give feedback about the coding choices they made.

In the end, when candidates are given a coding test comes down to personal preference and what works best for you and your team. Some might prefer to meet candidates first, then assess their technical skills to see if they can do the job. For our team, finding out whether they can do the job before ever meeting them in person has proven successful and allowed us to assemble a talented group of 18 front-end developers in just a few short years. If you’re interested in potentially being one of them, check out all of our current job openings at Ancestry.

The post Hiring: First Test Then Assess appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/test-then-assess/feed/ 0
Make your next UI library with an HTML APIhttp://blogs.ancestry.com/techroots/make-your-next-ui-library-with-an-html-api/ http://blogs.ancestry.com/techroots/make-your-next-ui-library-with-an-html-api/#comments Wed, 19 Jun 2013 22:36:09 +0000 Mitchell Harris http://blogs.ancestry.com/techroots/?p=683 Things are changing in the front end web world. Among those changes are HTML APIs.  Here’s the problem. You’ve made a webby-UI widget that is really cool. It’s so cool, that other people want to re-use it. How do you expose your widget so that other people can use it? In the old world, you… Read more

The post Make your next UI library with an HTML API appeared first on Tech Roots.

]]>
Things are changing in the front end web world. Among those changes are HTML APIs.  Here’s the problem. You’ve made a webby-UI widget that is really cool. It’s so cool, that other people want to re-use it. How do you expose your widget so that other people can use it? In the old world, you provided a Javascript API that clients would call, passing in the element. See jquery-ui, code mirror, or anything using Backbone or written as a jQuery plugin. For one or two UI widgets, we tolerate it. But if your page uses a lot of UI widgets, it’s misery. Backbone style misery.  The problem here is that view is being described in Javascript rather than HTML.  If you don’t think that’s extremely hard work, imagine generating ALL of your html using document.createElement.

 

The new world is better. It uses HTML APIs in the HTML itself. For example, Radian, which is powered by AngularJS allows you to specify plots and graphs in HTML, such as:

<plot height=600 aspect=1 stroke="none" marker="circle" axis-x-label="Age" axis-y-label="Height">
<points x="[[fam.age]]" y="[[fam.height]]" fill="[[mfpal(fam.sex)]]" marker-size="[[30*sqrt(fam.salaryhr)]]">
</points>
</plot>

Simply plunk this stuff down in your html, include the right script, and AngularJS + Radian + D3 do their magic.  I’d like to see more of these. I’d like to see accordions useable using <accordion>, and a calendar using a <calendar>.
AngularJS is a fantastic start for creating HTML APIs, but it isn’t the only way. On Ancestry.com’s Surname page we use an HTML API to define the svg graphics. Enter your surname, then view the source. You’ll see two odd looking tags:

 

<div id="surname-origin" context="surname.origin" surname=Harris options='{"limit": 3, "circleSpacing": 30}'></div>
<div context="surname.choropleth" surname=Harris id="surname-choropleth"></div>

 

Why do it this way? When other teams at Ancestry.com want to use our graphics they just include the tags on the page, and our HTML does the rest.

 

The Web world is getting more declarative. Join it. The next time you write a UI visual component, make it a tag.

The post Make your next UI library with an HTML API appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/make-your-next-ui-library-with-an-html-api/feed/ 0
Creating Random Data for Testinghttp://blogs.ancestry.com/techroots/creating-random-data-for-testing/ http://blogs.ancestry.com/techroots/creating-random-data-for-testing/#comments Wed, 12 Jun 2013 14:21:29 +0000 Anders http://blogs.ancestry.com/techroots/?p=80 In my experience, tests that emulate real-world usage and use real-world data, find more relevant bugs, convey intent more clearly, and exercise the system under test more thoroughly than tests that do not. Consider testing a cab service to assert that a given vehicle arrives at its destination: cabService.SendVehicleToDestination(vehicle, destination); Assert.AreEqual(vehicle.Location, destination); Now, it shouldn’t… Read more

The post Creating Random Data for Testing appeared first on Tech Roots.

]]>
In my experience, tests that emulate real-world usage and use real-world data, find more relevant bugs, convey intent more clearly, and exercise the system under test more thoroughly than tests that do not. Consider testing a cab service to assert that a given vehicle arrives at its destination:

cabService.SendVehicleToDestination(vehicle, destination);
Assert.AreEqual(vehicle.Location, destination);

Now, it shouldn’t particularly matter what vehicle is sent, or to where it is sent, but it’s often valuable to provide objects to methods that looks like the kind of objects an actual consumer of the service would send. Enter Randomator, a tool I created to use when scaffolding test objects:

public Vehicle MakeRandomVehicle()
{
    return new Vehicle
    {
        Color = Randomator.RandomColor(),
        Year = Randomator.RandomNumber(2000, DateTime.Now.Year + 1),
        Make = _makes[Randomator.RandomNumber(_makes.Length)],
        Owner = string.Format("{0} {1}", Randomator.RandomFirstName(
                Randomator.Gender.Any), Randomator.RandomLastName())
    };
}

A sample run produces:

Vehicle

Put it all together and the test looks like:

// Arrange
CabService cabService = new CabService();
Vehicle vehicle = MakeRandomVehicle();
String destination = Randomator.RandomLocation();

// Act
cabService.SendVehicleToDestination(vehicle, destination);

// Assert
Assert.AreEqual(vehicle.Location, destination);

This is, of course, a rather contrived example. We don’t have a cab service at Ancestry.com, fun as that would be, but as a family history company, we do have a lot person, event, location, and relationship objects for which this tool proves useful. Randomator has seen extensive use, enough so that I’ve ported it from C# to JavaScript and Java and made it available to the public under the MIT license. Check it out at: https://github.com/Ancestry/Testing-Utilities

The post Creating Random Data for Testing appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/creating-random-data-for-testing/feed/ 0
Creating Consistent Coding Standardshttp://blogs.ancestry.com/techroots/consistent-coding-standards/ http://blogs.ancestry.com/techroots/consistent-coding-standards/#comments Tue, 07 May 2013 17:25:23 +0000 Jeff Lord http://blogs.ancestry.com/techroots/?p=546 One of the key initiatives that our front-end development (FED) team has been tasked with at Ancestry.com is to help define, develop, document, implement, and enforce a global set of CSS/HTML standards for the organization. The fact that our team is in the business of creating standards (laws) and working to enforce (govern) them makes… Read more

The post Creating Consistent Coding Standards appeared first on Tech Roots.

]]>
One of the key initiatives that our front-end development (FED) team has been tasked with at Ancestry.com is to help define, develop, document, implement, and enforce a global set of CSS/HTML standards for the organization. The fact that our team is in the business of creating standards (laws) and working to enforce (govern) them makes calling ourselves “the FEDs” even more appropriate.

While there are obvious high level standards and best practices defined by W3C, there are a multitude of techniques that can be used to achieve similar results when coding web pages. Those differences have been the source of some lively, heated debates (and one near fistfight) among the FEDs on our team as we’ve tried to come to a general consensus on what should be considered a site-wide global standard. Just a small sampling of the topics that have been discussed by email and argued about over cubicle walls include:

  • Single vs. multi-line CSS properties
  • Alphabetical vs. grouped declaration order
  • Spacing after brackets, commas, colons, and selectors
  • Naming conventions (camel case vs. hyphens vs. underscores)
  • Lowercase vs. uppercase
  • Tables vs. divs for tabular data
  • Etc. etc.

In an effort to resolve our differences, we turned to the most knowledgeable and complete source of information known to man … Google. After tirelessly researching and scouring endless blogs and articles to defend the use of a preferred coding style, it became increasingly apparent that for every argument in favor of a particular technique there was an equally convincing case against its use. The only thing industry experts seem to agree on is that there’s disagreement when it comes to which coding style is best. Much like selecting a preferred browser, it’s difficult to convince a Firefox user that Chrome is the better choice since they both essentially do the same thing with subtle differences.

While we’ve had to agree to disagree on several of these topics, the biggest takeaway from our research is the importance of consistency. Even WordPress has documented its own defined set of coding standards it expects contributors to follow in order to maintain consistency. When a comment was made asking why they recommended avoiding the use of underscores, the simple reply was, “Because that’s our particular style.” What we have chosen for our standards at Ancestry.com might be different from what WordPress decided to go with, but that doesn’t necessarily make us right and them wrong as long as we’re both pushing for consistency.

Long story short, being consistent is more important than whether you use camel casing instead of hyphens or choose single lines over multi-lines in your style sheets. Having a consistent coding style based on your particular preferences will generate cleaner code that’s easier to read, use, and maintain going forward.

The post Creating Consistent Coding Standards appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/consistent-coding-standards/feed/ 0