This past week James O’Keefe presented on web application security and privacy at Code for Boston. His fantastic presentation is below and well worth the hour:
This past week James O’Keefe presented on web application security and privacy at Code for Boston. His fantastic presentation is below and well worth the hour:
After a few years of living in Boston I have now endured the apartment hunting experience twice. The first time I was looking for a room and roommates in a place near Harvard Law School where my fellowship was located. The second time I started looking for a unit with my girlfriend in Southie. These were different experiences that both turned out to be tougher to surmount than I expected. However I learned there are things you can do to set your expectations and make your apartment hunt go smoother.
Looking for roommates and an apartment is challenging because you are trying to get the kind of unit you like and find a group of people you will fit in with. When I was in that situation I went to about twenty showings and was rejected by most of them. Competition is fierce and you can only gleam so much from a first meeting. The most important thing is to be persistent. Furthermore, you should prioritize the roommates over the dwelling unit quality. However, if you can find roommates first and search for a dwelling unit that might be a better way to go.
If you do that you get to learn about the world of brokers. Brokers can work for buyers or sellers. You want a broker that is working for you. The way you find a broker that works for you is you go to a Zillow open house and ask if the broker can help you access other properties. They have access to the MLS. You can then work with them to schedule showings and try to get approved for a property.
Knowing these things is not going to make apartment hunting easy, but hopefully will make it a little easier.
Tonight at Code for Boston the folks who run Cryptoparty are going to run a web application security workshop. I asked for this programming to be put together because in my own education about web application development I have found material about security to be lacking or of low quality. Unfortunately much of the mainstream content can be overly alarmist and lack perspective. By bringing in a professional to educate the group about best practices I am hoping to develop a checklist of things that I will think about as I develop my web applications going forward. If you want to tune in we will be broadcasting it on Facebook Live at 7:15 p.m..
My group at the Metropolitan Area Planning Council is hiring a front-end web developer. We currently have a team of three people including two full-stack developers and need someone that can help us with our front-end design and code. We hope to hire someone with design skills. While we sometimes work with a digital designer we have some lighter touch projects that could benefit from a person with just the right amount of design intuition. If you love visualizing data and building charts and data dashboards, this position could be a great fit for you. We want someone that can take our interfaces and visualizations from functional to fantastic. If your passions are JavaScript, CSS, and data then you will probably love working with us.
At MAPC we have been thinking more about making our web applications accessible to all our users. Unfortunately standard web frameworks and tools do not bake this functionality in. Accessibility is its own specialization with code and nuances that software developers have to learn on top of everything else they do. The good news is that as this issue has become more prominent tools are emerging to make it easier to automate making your application accessible. One tool I started experimenting with is the axe-matchers gem from Deque.
In order to use this tool you should add gem axe-matchers to your test group in your Gemfile, then require 'axe/rspec' in spec_helper.rb. After that it is as simple as adding a test to your Rspec test suite:
it "is accessible", js: true do
create(:page)
visit "/"
expect(page).to be_accessible
end
There are methods to get granular with different parts of your pages if you want to break it up. The nice thing is that axe-matchers provides specific actionable feedback with links that explain the rationale for the rules. Example output is below:
3) link-name: Links must have discernible text (serious)
https://dequeuniversity.com/rules/axe/3.1/link-name?application=axeAPI
The following 3 nodes violate this rule:
Selector: .footer-right > a:nth-child(1)
HTML: <a href="https://twitter.com/mapcmetroboston"><i class="fa fa-twitter"></i></a>
Fix all of the following:
- Element is in tab order and does not have accessible text
Fix any of the following:
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
- Element's default semantics were not overridden with role="presentation"
- Element's default semantics were not overridden with role="none"
Selector: .footer-right > a:nth-child(2)
HTML: <a href="https://www.instagram.com/mapcmetroboston"><i class="fa fa-instagram"></i></a>
Fix all of the following:
- Element is in tab order and does not have accessible text
Fix any of the following:
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
- Element's default semantics were not overridden with role="presentation"
- Element's default semantics were not overridden with role="none"
Selector: a:nth-child(3)
HTML: <a href="https://www.facebook.com/mapcmetroboston"><i class="fa fa-facebook"></i></a>
Fix all of the following:
- Element is in tab order and does not have accessible text
Fix any of the following:
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
- Element's default semantics were not overridden with role="presentation"
- Element's default semantics were not overridden with role="none
As a developer using an automated test that provides specific feedback and suggested remedies makes implementing accessibility best practices much easier. Given how easy this was to implement, trying this out is an easy win for any Rails developer.