[This post originally appeared on my company blog here. I am re-posting it here for posterity.]
Hi, I'm Benjamin Haas, and I'm a software engineer and manager at Control Group. I am also a developer advocate, which means that in addition to helping build great products and experiences, I try to ensure that developers have a voice in all company-wide initiatives, projects, and processes. Furthermore, I am involved with our developer community outreach initiative, as we recognize that we are part of a larger group of companies and individuals that are actively working toward the technological transformation of New York City.
One aspect of developer advocacy and outreach that is important for me is being an active part of our Women in Technology program. Gender diversity in the workplace is a goal that I am happy to say I am working toward, and I am joined by a pleasingly well-rounded crew of co-workers.
My friend Jackie from Only Make Believe recently asked me to speak at the Emerging Leaders of New York Arts (ELNYA) event at the Talking Transition tent in New York. Talking Transition is an initiative to give New Yorkers the chance to take part in a conversation with the incoming DeBlasio mayoral administration. At the ELNYA event, I represented the city's tech needs, as they intersect with needs of the arts and arts administrators community. Here is the gist of what I said.
Let's say you're busy working on your project, creating feature branches right and left to build out your super sweet app. Then your dev team decides to change their feature branch naming convention. How do you proceed without having an aneurysm? Can you easily accomodate your team's plan and not end up wanting to punch people in the face? Yep! As a matter of fact it's super simple to rename your branches. Here's how.
When Marci and I went to New Orleans last year, we solicited the advice of our friends (Joshua M. Bernstein!Scott Gold! Molly Dorfman!) regarding where to eat and drink. I compiled their recommendations, along with some spots from eater.com, and made this Google map. Since then I've shared this so many times that I figured I should just publish it here. Enjoy, and let me know if anything is out of date.
It has been a year since I originally wrote the "Installing Yii Users and Rights in 5 Steps" tutorial, and both the Yii framework and the modules themselves have had some updates since then. I made some slight tweaks to the tutorial and updated the git repository to match the current builds.
I just started Yii New York City, a meetup for NYC-area developers interested in the Yii Framework. I'm hoping we can get together monthly, or every other month, and talk about the cool stuff we're building in Yii. There will be introductions, roundtable discussions, demos, and most importantly, free food and beer! My company, Control Group, will be hosting the meetups, and you should come check us out even if just for the awesome views of lower Manhattan.
It's easy enough to determine how the Yii Rights module works when used to perform inline access control checks in your code. You simply call ($user->checkAccess($operation) === true), and the internal details are easy enough to dig into. But how does it work with your controllers to allow or deny access to a page (or more specifically, an action in your controller)?
If you haven't yet read up on access control filters, you should check out the official Yii Controller Basics first and get familiar with filter chains. Then come back and read the rest of this post.
Yii provides an excellent set of tools for displaying paged data, namely the CListView and CGridView widgets. These widgets are easy to use, are highly customizable, and provide the kind of pager that is in use all over the web. Which makes it all the more strange that the pager doesn't work quite as expected.
The strange default behavior is that built-in css attributes hide the "First" and "Last" buttons. In fact, if you're like me, you didn't even know that the pager had a "First" and "Last" button until you started looking into putting ones in there. If you view the page source and scroll down to the pager, you'll see these elements, each of them contained within <li class="first"> and <li class="last"> tags, respectively. These tags are targeted by a display:none css attribute contained in the default pager stylesheet.
I have no idea why these are hidden by default, but it's not too much work to make them visible.