Most UNIX users have heard of the nice utility used to run a command with a lower priority to make sure that it only runs when nothing more important is trying to get a hold of the CPU:

nice long_running_script.sh

That's only dealing with part of the problem though because the CPU is not all there is. A low priority command could still be interfering with other tasks by stealing valuable I/O cycles (e.g. accessing the hard drive).

Prioritizing I/O

Another Linux command, ionice, allows users to set the I/O priority to be lower than all other processes.

Here's how to make sure that a script doesn't get to do any I/O unless the resource it wants to use is idle:

sudo ionice -c3 hammer_disk.sh

The above only works as root, but the following is a pretty good approximation that works for non-root users as well:

ionice -n7 hammer_disk.sh

You may think that running a command with both nice and ionice would have absolutely no impact on other tasks running on the same machine, but there is one more aspect to consider, at least on machines with limited memory: the disk cache.

Polluting the disk cache

If you run a command (for example a program that goes through the entire file system checking various things, you will find that the kernel will start pulling more files into its cache and expunge cache entries used by other processes. This can have a very significant impact on a system as useful portions of memory are swapped out.

For example, on my laptop, the nightly debsums, rkhunter and tiger cron jobs essentially clear my disk cache of useful entries and force the system to slowly page everything back into memory as I unlock my screen saver in the morning.

Thankfully, there is now a solution for this in Debian: the nocache package.

This is what my long-running cron jobs now look like:

nocache ionice -c3 nice long_running.sh Turning off disk syncs

Another relatively unknown tool, which I would certainly not recommend for all cron jobs but is nevertheless related to I/O, is eatmydata.

If you wrap it around a command, it will run without bothering to periodically make sure that it flushes any changes to disk. This can speed things up significantly but it should obviously not be used for anything that has important side effects or that cannot be re-run in case of failure.

After all, its name is very appropriate. It will eat your data!

On Monday, I will fly out for DrupalCON Portland. This will be my 14th (!) DrupalCON, dating back to 2006.

There was some question whether I would attend. For the record, Morten was wrong: I will be there.

For more information about why the questions, feel free to read the eulogy I just wrote for my father.

I will mostly be spending my time at the Palantir booth, and I am looking forward to spending time with some dear friends and colleagues. I am perhaps most looking forward to the benefit event for Aaron Winborn on Monday evening.

For more information about Palantir activities, see our blog post about our events and sessions.

See everyone soon.

Thanks to DoctorMo for the hilarious photo. It’s just so good.

We’ve got Classes working, the usual fixes from the ‘crew, and native macros. Huzzah! 

I’ve had to take the site down for now (well, stop updating it) because of a vulnerability I introduced (macros allow arbitrary code to run), which means, if anyone’s keen, they should add the sandboxing code to the Hy Site as well!

More coming soon!

The ASF is holding it’s Annual Member’s Meeting this coming week, where the Membership elects a new board of directors along with other matters, like voting in new Member candidates. While I was nominated last year, I was not elected. I would have been sad about not getting a seat, except for the fact that such other fabulously good people got elected instead (including two new directors who got to serve their first terms, Rich and Ross, yay!).

Director candidates at the ASF write position statements about what their objectives for being a director are in preparation for the voting process. Since I write what I believe in, I also am posting my statement here, publicly. One of the biggest issues for the smooth functioning of the ASF as a home for healthy projects is doing a better job of explaining how we work – I hope this helps people understand us Apache types just a little bit better. You can also see what I wrote last year.

If you’re wondering how governance at Apache really works, I’ve written an Apache governance overview too.

Shane Curcuru (curcuru) Director Position Statement v2.0 statement

As the ASF scales in people, projects, and impact on the world, we
need directors that can ensure our organization stays true to it’s
ideals; that can delegate appropriately and efficiently to officers
and PMCs; and especially that can communicate calmly, clearly,
and consistently in all of their communications.

As we surpass one million $ in assets, with thousands of committers, nearly a gross of projects, and an huge impact both on the software world with our technology, and on the larger world of computer users with our products, I believe it’s important to do an even better job of explaining what the ASF is about and how the Apache Way works.

While we don’t need more rules, we do need to do a much better job of explaining what our few hard requirements are, as well as showcasing the wealth of best practices that our projects have created. This is important both to let the world know who we are, and also to ensure that the many different communities of contributors can more easily understand how to work with our projects.

With the fast growing scale of our organization, it is critical that directors and corporate officers can communicate clearly, calmly, and professionally in all of their Apache related activities – whether or not they’re explicitly showing which hat they’re wearing at the moment. As our impact grows, so does the impact of our words, both inside our communities, attracting (or not) new members to our communities, and also on the larger world of corporations, universities, and other computer using peoples. Even if we as long-time denizens of members@ understand which hat a director or officer is wearing when they speak, most other human beings and most other contributors don’t necessarily see the distinction.

It has been a long time since we held in-person member’s meetings
where everyone knew each others personal style. As we grow,
we need to be sure that we’re making it easy for new members and
contributors to feel welcomed and understand how Apache works. We also need to ensure that we both can keep the sense of family and enjoyable, collaborative community that the membership and our projects have, and that we manage the affairs of the ASF and of our projects in a consistent, documented, and professional manner.

About Shane

I’ve been a committer since November 1999, a Member since 2002,
and VP, Brand Management since 2009.

I am employed by IBM in the HR division as an Applications Architect. My employment and income have been unrelated to my work at the ASF for many years, and I will always clearly separate volunteer work from employer-funded work.

My involvement in the ASF is driven by a belief in, and a love of,
the ASF, and is not influenced by politics or finances. I live in
Massachusetts with my wife, young daughter, and 2 cats. I view
directorships and officer positions at the ASF as serious commitments.

I will attend every board meeting if elected.

• Deep In The Game: Not The RTE Guide

  Good interview with Alan Maguire, the satirist behind the very funny @NotTheRTEGuide on Twitter:

  I’ve always been a huge fan of TV Go Home and Charlie Brooker in general and it seemed like Irish TV and culture was a good target for the kind of barbed surrealism that he does. (I’m not claiming I’m in his league or anything but he’s the main influence). I was really surprised that there hadn’t been a parody RTÉ Guide already. TV listings are 140-ish characters already and the RTÉ Guide has a kind of weird place in Irish culture where everybody knows it but nobody our age really has any idea of what’s in it anymore. We associate it with a small-c conservatism, or I did at least and I play that up occasionally with the account.

  (tags: nottherteguide rte rte-guide ireland funny satire interviews)

• My Philosophy on Alerting

  ‘based on my observations while I was a Site Reliability Engineer at Google.’ – by Rob Ewaschuk; very good, and matching the similar recommendations and best practices at Amazon for that matter

  (tags: monitoring ops devops alerting alerts pager-duty via:jk)

I came across this question on the Stack Exchange site Unix & Linux. The question interested me so I answered it but thought I’d cross post it on my blog as well, given I took a pretty significant amount of time to put together a test case and write-up of how the solution ultimately worked.

Problem

I’m using rsync to copy some files from a share to another.

Recursively, I need to:

- delete files at the destination that are deleted in the origin
- Only sync php and js files
- exclude de rest of file types
- Don’t delete .svn/ directory in the destination

If I use this:

rsync -zavC --delete --include='*.php' --include='*.js' --exclude="*" /media/datacod/Test/ /home/lucas/Desktop/rsync/

Then rsync is not recursive because exclude=”*” excludes all files but also folders

If I add --include="*/" then the .svn/ directory gets deleted (it also gets included)

How can I solve this mind blasting dilemma?

Solution

The solution I ultimately came up with made use of a little known feature, at least to me, called filters. Filters allow you to play games with the includes/excludes by protecting portions based on regular expressions. Read on, I’ll discuss them further down.

1 2 rsync -avzC --filter='-rs_*/.svn*' --include="*/" --include='*.js' --include='*.php' \ --exclude="*" --delete dir1/ dir2/ test data

To help determine if my solution was going to work or not I created some sample data so that I could test it out. For starters I wrote a script that would generate the data. Here’s that script, setup_svn_sample.bash:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #!/bin/bash   # setup .svn dirs mkdir -p dir{1,2}/dir{1,2,3,4}/.svn   # fake data under .svn mkdir -p dir1/dir{1,2,3,4}/.svn/origdir mkdir -p dir2/dir{1,2,3,4}/.svn/keepdir   # files to not sync touch dir1/dir{1,2,3,4}/file{1,2}   # files to sync touch dir1/dir{1,2,3,4}/file1.js touch dir1/dir{1,2,3,4}/file1.php

Running the above script produces the following directories (dir1 & dir2):

source dir

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 $ tree -a dir1 dir1 |-- dir1 | |-- file1 | |-- file1.js | |-- file1.php | |-- file2 | `-- .svn | `-- origdir |-- dir2 | |-- file1 | |-- file1.js | |-- file1.php | |-- file2 | `-- .svn | `-- origdir |-- dir3 | |-- file1 | |-- file1.js | |-- file1.php | |-- file2 | `-- .svn | `-- origdir `-- dir4 |-- file1 |-- file1.js |-- file1.php |-- file2 `-- .svn `-- origdir

destination dir

1 2 3 4 5 6 7 8 9 10 11 12 13 14 $ tree -a dir2 dir2 |-- dir1 | `-- .svn | `-- keepdir |-- dir2 | `-- .svn | `-- keepdir |-- dir3 | `-- .svn | `-- keepdir `-- dir4 `-- .svn `-- keepdir

Running the above rsync command which includes the --filter below we can see that it’s only syncing the files that match the --include patterns:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 rsync -avzC --filter='-rs_*/.svn*' --include="*/" --include='*.js' --include='*.php' \ --exclude="*" --delete dir1/ dir2/ sending incremental file list dir1/file1.js dir1/file1.php dir2/file1.js dir2/file1.php dir3/file1.js dir3/file1.php dir4/file1.js dir4/file1.php   sent 480 bytes received 168 bytes 1296.00 bytes/sec total size is 0 speedup is 0.00

Resulting dir2 afterwards:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 $ tree -a dir2 dir2 |-- dir1 | |-- file1.js | |-- file1.php | `-- .svn | `-- keepdir |-- dir2 | |-- file1.js | |-- file1.php | `-- .svn | `-- keepdir |-- dir3 | |-- file1.js | |-- file1.php | `-- .svn | `-- keepdir `-- dir4 |-- file1.js |-- file1.php `-- .svn `-- keepdir Why does it work?

The key piece to this script is to make use of the filters capability of rsync. Filters allow you to remove files from the matched set at various points in the command. So in our case we’re filtering any files that match the pattern */.svn*. The modifiers -rs_ tell the filter that we want to filter on both the source side as well as the target side.

excerpt from the FILTER NOTES section of rsync’s man page

- An s is used to indicate that the rule applies to the sending side. When a rule affects the sending side, it prevents files from being
transferred. The default is for a rule to affect both sides unless --delete-excluded was specified, in which case default rules become sender-side only. See also the hide (H) and show (S) rules, which are an alternate way to specify sending-side includes/excludes.

- An r is used to indicate that the rule applies to the receiving side. When a rule affects the receiving side, it prevents files from being deleted. See the s modifier for more info. See also the protect (P) and risk ® rules, which are an alternate way to specify receiver-side includes/excludes.

See man rsync for more details.

Tips for figuring this out (hint using --dry-run)

While describing how to do this I thought I’d mention the --dry-run switch to rsync. It’ extremely useful in seeing what will happen without having the rsync actually take place.

For Example

Using the following command will do a test run and show us the decision logic behind rsync:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 rsync --dry-run -avvzC --filter='-rs_*/.svn*' --include="*/" \ --include='*.js' --include='*.php' --exclude="*" --delete dir1/ dir2/ sending incremental file list [sender] showing directory dir3 because of pattern */ [sender] showing directory dir2 because of pattern */ [sender] showing directory dir4 because of pattern */ [sender] showing directory dir1 because of pattern */ [sender] hiding file dir1/file1 because of pattern * [sender] showing file dir1/file1.js because of pattern *.js [sender] hiding file dir1/file2 because of pattern * [sender] showing file dir1/file1.php because of pattern *.php [sender] hiding directory dir1/.svn because of pattern */.svn* [sender] hiding file dir2/file1 because of pattern * [sender] showing file dir2/file1.js because of pattern *.js [sender] hiding file dir2/file2 because of pattern * [sender] showing file dir2/file1.php because of pattern *.php [sender] hiding directory dir2/.svn because of pattern */.svn* [sender] hiding file dir3/file1 because of pattern * [sender] showing file dir3/file1.js because of pattern *.js [sender] hiding file dir3/file2 because of pattern * [sender] showing file dir3/file1.php because of pattern *.php [sender] hiding directory dir3/.svn because of pattern */.svn* [sender] hiding file dir4/file1 because of pattern * [sender] showing file dir4/file1.js because of pattern *.js [sender] hiding file dir4/file2 because of pattern * [sender] showing file dir4/file1.php because of pattern *.php [sender] hiding directory dir4/.svn because of pattern */.svn* delta-transmission disabled for local transfer or --whole-file [generator] risking directory dir3 because of pattern */ [generator] risking directory dir2 because of pattern */ [generator] risking directory dir4 because of pattern */ [generator] risking directory dir1 because of pattern */ [generator] protecting directory dir1/.svn because of pattern */.svn* dir1/file1.js dir1/file1.php [generator] protecting directory dir2/.svn because of pattern */.svn* dir2/file1.js dir2/file1.php [generator] protecting directory dir3/.svn because of pattern */.svn* dir3/file1.js dir3/file1.php [generator] protecting directory dir4/.svn because of pattern */.svn* dir4/file1.js dir4/file1.php total: matches=0 hash_hits=0 false_alarms=0 data=0   sent 231 bytes received 55 bytes 572.00 bytes/sec total size is 0 speedup is 0.00 (DRY RUN)

In the above output you can see that the ./svn directories are being protected by our filter rule. Valuable insight for debugging the rsync.

References

- Delete extraneous files from dest dir via rsync?
- Above scripts in a tarball

Readers who viewed this page, also viewed:

• Formatting text using Textile
• Powered by Where did they go from here?

If I did everything right, this post will not appear on any RSS feed yet still make it to my blog to maintain history.

The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1088
  • Affecting Jessie: 214 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 183 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 43 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 15 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 125 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 31 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 0 bugs are in packages that are unblocked by the release team.
      • 31 bugs are in packages that are not unblocked.

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Diff 43 284 (213+71) 468 (332+136) +184 (+119/+65) 44 261 (201+60) 408 (265+143) +147 (+64/+83) 45 261 (205+56) 425 (291+134) +164 (+86/+78) 46 271 (200+71) 401 (258+143) +130 (+58/+72) 47 283 (209+74) 366 (221+145) +83 (+12/+71) 48 256 (177+79) 378 (230+148) +122 (+53/+69) 49 256 (180+76) 360 (216+155) +104 (+36/+79) 50 204 (148+56) 339 (195+144) +135 (+47/+90) 51 178 (124+54) 323 (190+133) +145 (+66/+79) 52 115 (78+37) 289 (190+99) +174 (+112/+62) 1 93 (60+33) 287 (171+116) +194 (+111/+83) 2 82 (46+36) 271 (162+109) +189 (+116/+73) 3 25 (15+10) 249 (165+84) +224 (+150/+74) 4 14 (8+6) 244 (176+68) +230 (+168/+62) 5 2 (0+2) 224 (132+92) +222 (+132/+90) 6 release! 212 (129+83) +212 (+129/+83) 7 release+1 194 (128+66) +194 (+128/+66) 8 release+2 206 (144+62) +206 (+144/+62) 9 release+3 174 (105+69) +174 (+105/+69) 10 release+4 120 (72+48) +120 (+72/+48) 11 release+5 115 (74+41) +115 (+74/+41) 12 release+6 93 (47+46) +93 (+47/+46) 13 release+7 50 (24+26) +50 (+24/+26) 14 release+8 51 (32+19) +51 (+32/+19) 15 release+9 39 (32+7) +39 (+32/+7) 16 release+10 20 (12+8) +20 (+12/+8) 17 release+11 24 (19+5) +24 (+19/+5) 18 release+12 2 (2+0) +2 (+2/+0)

Graphical overview of bug stats thanks to azhag:

Together with Uwe Schindler I had published a series of articles on Apache
Lucene at Software and Support Media’s Java Mag several years ago. Earlier this
year S&S kindly invited my to their BigDataCon - co-located with JAX to give a
talk of my choosing that at least touches upon Lucene.

Thinking back and forth about what topic to cover what came to my mind was to
give a talk on how easy it is to do text classification with Mahout when
relying on Apache Lucene for text analysis, tokenisation and token filtering.
All classes essentially are in place to integrate Lucene Analyzers with Mahout
vector generation - needed e.g. as a pre-processing step for classification or
text clustering.

Feel free to check out some of my sandbox code over at <a
href=“http://github.org/MaineC/sofia”>github</a>.

After attending the conference I can only recommend everyone interested in Java
programming and able to understand German to buy a ticket for the conference.
It’s really well executed, great selection of talks (though the sponsored
keynotes usually aren’t particularly interesting), tasty meals, interesting
people to chat with.

Media queries are a key part of responsive web design, because they control at what width (among other things) different CSS rules kick in.

"Breakpoint makes writing media queries in Sass super simple," say Mason Wendell and Sam Richard, creators of the extension to Compass, and they're right. It's not surprising that we'd want them to present at Drupalcon, since design in Drupal, like web design everywhere, has been embracing responsive web design as a fundamental principle. (Side note: This website is in the midst of a responsive web design overhaul. Cobbler's children and all that.)

I spoke to Mason and Sam about how Breakpoint makes responsive web design even easier. Don't miss their Drupalcon Portland frontend session, “Managing Responsive Web Design with Sass and Breakpoint,” on Thursday at 10:45 AM.

IB: What motivated you to create Breakpoint? How has it changed your own workflow?

MW: Before Sass 3.2 came out I had written an article for The Sass Way that previewed some of it's new features, including the ability to use variables in media queries. I created an example that baked in some names for breakpoints into a kind of "master mixin" for media queries. On my next responsive project I put the theories I'd written for that post into practice, and found that I could refine that approach. If I assigned a variable to each media query first the approach would be very flexible. Then when noticed that I wrote min-width queries way more often than any other type I set up defaults that made creating media queries very fast.

MW: There was a side effect that I think is more useful though. By assigning names to each of my media queries I'm able to keep them in context in a much more effective way. If I some media queries to deal with the width of a nav element, and then later I add an item to that nav, I can change the value of that variable and all the associated queries are adjusted. This is even more effective when handing code back and forth within a team.

SR: Breakpoint was created with the motivation to ease many of the pain points of working with media queries in CSS. The biggest pain point that Breakpoint solves is providing meaningful semantics to your media queries. When building content based responsive sites, early in your design process two unrelated items may happen to break at the same points, but as your project grows, those points may change and a simple find and replace will have unintended consequences. This is probably the biggest workflow win to using Breakpoint, all of your media queries now have proper semantics.

SR: The other big win for my workflow is Breakpoint's no-query fallback, allowing me to very easily add in fallback code for any of the media queries I write.

IB: What can Breakpoint do that just assigning variable names to specific min-widths can't?

SR: For starters, Breakpoint handles much more than min-width queries. It is designed to be future friendly and currently supports all CSS level 3 and level 4 media queries. Additionally, it's syntax is easy to use to create complex media queries, including both and and or media queries. It has native handling for all of the different media query requirement for resolution (of which you need to write at least four different queries for currently) while just writing the standard. The no-query fallbacks are a huge win as well.

MW: The main benefit is that you can assign names and manage your media queries with variables. This helps you avoid having them scattered around your SCSS, and makes is easy to understand how they're related and affect each other.

MW: While Breakpoint is optimized for min-width because they're used most often it doesn't stop there. There are a number of shortcuts built in, for fencing min- and max- values, converting pixels to ems, and even vendor prefixed queries like resolution.

MW: We even created a way to Breakpoint to report back to you what queries are in a particular context. Singularity GS uses this feature to kind of magically create responsive grid systems.

SR: Of all of Breakpoint's features, probably the least used, but most powerful is Breakpoint Context. This allows you to call a function anywhere and get the current media query context allowing for amazingly intelligent mixins and functions to be written in Sass, something unique to Breakpoint that you simply don't have with interpolating variables.

IB: Are there any responsive web design aspects specific to Drupal theming/frontend development that Breakpoint helps with?

SR: There is nothing Drupal specific that Breakpoint helps with. Breakpoint, like Sass, was built to be backend independent. This means that if you are building any site, regardless of if it's a Drupal site or a Node site or a static site, Breakpoint is able to do its job handily without being caught up in being tied to a specific backend technology.

MW: One of the things I love about working with Sass is that it's not Drupal-specific, and it's meant to be used anywhere on the web. Breakpoint follows that example.

IB: Is Breakpoint a successor to Respond-To, or will that continue to get developed?

SR: In a way, yes and no. Respond-To was written before Breakpoint, but upon Breakpoint's release, it was decided that our efforts should be focused on a unified Media Query engine, with Respond-To as a wrapper syntax for Breakpoint. This is how the current Respond-To project exists. As of Breakpoint 2.0, the Respond-To mixin has been incorporated into Breakpoint core, so you now can use Respond-To without needing an additional Compass extension!

IB: Do you use Breakpoints module (in Drupal 8 core)? Or do you just do all of that through Sass?

SR: I personally truly dislike the Breakpoint module. Every use case I've heard for it seems to be based on the thinking that sites have three or four breakpoints and that everything can be boiled down into an easy to use admin interface. There are no standard breakpoints, period, and good, reasonably complex responsive sites will usually have 20 or more breakpoints. Responsive cannot be done from the backend, and the Breakpoint module encourages you to do so (as does the Spark layout initiative).

IB: Do you think any aspects of Breakpoint might get rolled directly into Sass in the future?

MW: It's possible, but we probably won't move the obvious parts to the Sass language. There are some helper functions that we've written in Ruby that would be very useful in Sass core. Once that's in we'll be able to offer Breakpoint without Compass.

SR: I do not believe Breakpoint will be rolled directly into Sass, nor would I want it to be, as it is out of scope of Sass core. As much as I like them, I even think the color functions in Sass are out of scope for it. Sass core should simply be the language and the bare minimum function base for it to be useable. Sass doesn't ship with any mixins, and I think it should probably stay that way. That being said, Breakpoint is fairly stable; our 1.3 release stood stable for six or so months without needing any changes until we rewrote the whole thing for our 2.x release, so maybe being merged into Compass isn't out of the question, but I do not see a need for that.

IB: I hear in addition to Breakpoint, Sam went and created some kind of magic box of Sass called Toolkit. Want to say more about that?

SR: Toolkit started life as RWD Kickstart, a project Mason and I kind of made up on the spot a year ago at one of the first New York Sass meetups. Its original goal was simply to be a collection of Compass templates to make pulling in media query and grid solutions together easily. Since then, it's evolved to be more of a collection of Progressive Enhancement, Design in Browser, and Modern Web Development tools, a toolkit if you'll let me, of useful tools. I'd say the four biggest thing that Toolkit has are a modern Clearfix mixin, progressive enhancement replace text mixins, a triangle generation mixin, and an intrinsic ratio mixin to make using intrinsic ratios super easy. It also adds *, *:before, *:after { box-sizing: border-box} and img, video { max-width: 100%; height: auto; } to your stylesheets, which are the first two things I do for any responsive project.

SR: Toolkit's templates have also evolved, Where originally there were five some odd different templates to choose from, now there are just two, a basic one to set up a basic partial structure, and a responsive web design one that pulls in Breakpoint 2.x for media queries and Singularity 1.x for grids.

IB: You sure know those late twentieth-century presidents.

MW: With a name like Breakpoint, how could I not revisit the cinema classic Point Break. Bodhi and his gang of thrill-seeking bank-robbing surfers evaded the FBI for years until the newly minted Special Agent Johnny Utah was on the case. I think we can all agree that there's a poignant metaphor for web designer there. And some pretty sweet gifs.

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.

27.13. inspect — Inspect live objects — Python v2.7.5 documentation

The inspect module comes as part of the standard library of Python. It allows you to inspect live objects at run time by using its methods.

Here is an example:

import inspect
class Bar( object):
    def foo( self ):
        print "in Bar.foo 4"
        self .a = 1
        self .di = { 'b' : 2, 'c' : 3 }
        self .li = [  4, 5, 6 ]

bar = Bar()
bar.foo()
for member in inspect.getmembers(bar):
    print member

Running the above code gives this as (partial) output:

in Bar.foo 4

('__dict__', {'a': 1, 'li': [4, 5, 6], 'di': {'c': 3, 'b': 2}})
('__doc__', None)
('a', 1)
('di', {'c': 3, 'b': 2})
('foo', bound method Bar.foo of __main__.Bar object at 0x4035bfac)
('li', [4, 5, 6])

This shows both the bound methods and the member variables of the instance bar.

The inspect module can do a lot of other things too. Check the docs for it, linked at the top of this post.

You can also modify and run the above code snippet at this codepad.org URL:

http://codepad.org/dMLmkhQ6

It may not last there for too long, though, since they probably delete pastes to make room for new ones.

- Vasudev Ram
dancingbison.com

Vasudev Ram

Do you use PostgreSQL and truly believe it’s “the world’s most advanced open source database” and that its upcoming 9.3 release will make it even more awesome?

Do you also use Python and believe it’s “an easy to learn, powerful programming language” with “elegant syntax” that makes it an ideal language for developing applications and tools around PostgreSQL, such as Pyrseas?

Then we could use your help. For starters, we want to add support for the MATERIALIZED VIEWs and EVENT TRIGGERs coming up in PG 9.3.

We have also been requested to add the capability to load and maintain “static data” (relatively small, unchanging tables) as part of yamltodb, so that it can be integrated more easily into database version control workflows.

And for the next release, Pyrseas 0.7, we’d like to include the first version of the database augmentation tool which will support declarative implementation of business logic in the database–starting off with audit trail columns. Some work has been done on this already, but it needs integration with the current code and tests.

Or perhaps coding is not your forte, but you’re really good at explaining and documenting technical “stuff”. Then you could give us a hand with revamping the docs, maybe writing a tutorial so that users have a smooth ride using our tools.

Or maybe you have your own ideas as to how improve the PostgreSQL version control experience. We’d love to hear those too.

If you’d like to help, you can fork the code on GitHub, join the mailing list and introduce yourself, or leave a comment below.

Filed under: PostgreSQL, Python, Version control

Thanks to a kind offer from Sylvestre Ledru () we have a venue for this year’s GNU Hackers Meeting: we will be at IRILL () in Paris, France, for the second time after the very successful 2011 edition. Since I live near Paris and I also happen to work at IRILL once or twice a week I’ve decided to do something to help organize the event, along with Sylvestre and Dodji Seketeli () who graciously volunteered as well. The meeting will take place in late August 2013: right now we’re deciding whether to have talks on Friday 23 and Saturday ... [Read more]

The people have spoken, and the DA has answered! There will now be an AV equipped BoF room devoted to the Art of Project Management in its many forms. We’d like to send a shout out to the DA for the help in securing a space*, to our community’s project managers for your feedback and ideas and to the presenters who generously offered to join in and share their ideas!

While I was working on a project here at Propeople, I had a requirement to limit the options for an exposed filter in order to get only options that will give some results. Unfortunately Views don’t provide this kind of functionality.

Let's start with an example. I have a Content Type called "People" which has a Term Reference select list. Generally speaking we have to alter the “views_exposed_form”.

Follow the next 3 steps:

1. Create a custom module and implement hook_form_alter(). I strongly recommend not to use a form-specific alteration like hook_form_FORM_ID_alter() instead of global hook_form_alter() because it is difficult to control and manage your code. function [my-module-name]_form_alter) {
dsm($form); //be sure to enable devel module.
}

2. Now you should get the content from the $form variable

3. Next, we have to select all the matching results based on our conditions in order to edit the options from $form['term']['#options']. Personally, I prefer to query directly with db_select, but feel free to use EntityFieldQuery if you prefer.

function [my-module-name]_form_alter(&$form, &$form_state, $form_id) {
if ($form['#id'] == 'views-exposed-form-people-list-page') {

$available_terms = _get_available_terms();

if (isset($available_terms)) {
// Unset the existing list and add new one with available terms.
unset($form['term']['#options']);
$form['term']['#options']['All'] = '- Any Term -';
foreach ($available_terms as $available_term) {
$form['term']['#options'][$available_term->tid] = $available_term->name;
}
} else {
// Unset all options except '- Any -'
unset($form['term']['#options']);
$form['term']['#options']['All'] = '- Any Term -';
}
}
}

function _get_available_terms() {
$query = db_select('taxonomy_term_data', 'terms');
$query->join('field_data_field_reference', 'term_ref', 'term_ref.field_reference_tid = terms.tid');
$term_result = $query
->fields('terms', array('tid', 'name'))
->execute()
->fetchAll();
return $term_result;
}

That's it. Follow us on Twitter, Facebook and subscribe to Propeople RSS feed to stay informed about our activity inside the Drupal community.

Language English Tags: DrupalDevelopmentTutorialsCheck this option to include this post in Planet Drupal aggregator: planet

It’s that time again! Planning for PyCon 2014 is well underway, and we’re currently preparing for the launch of our new site. With the launch comes a unique opportunity: Is your organization interested in being a launch day sponsor?

PyCon 2013 launched on July 9, 2012 with 21 sponsors pledging support, leading the charge that drew over 150 organizations to pitch in to the biggest and best Python conference yet. We’re planning a similar go-live date for the 2014 site, and we’re building up our cadre of supporters for the April 9-17 conference taking place in Montreal, Quebec, Canada.

Your organization’s support enables PyCon to do the awesome things. 2013 introduced a number of new events suggested by the community, so we’d like to keep doing those things and more. For example, the inaugural Young Coders tutorial was such a hit that there are already plans around the world for user groups to replicate it, and we’re looking forward to doing a PyCon 2014 rendition. Programs like Financial Aid, which saw its budget increased and then quickly doubled to reach $100,000 USD, are greatly enhanced by the giving of sponsors.

Along with benefiting the community, sponsorship of PyCon brings many benefits to its supporters. We hear it year after year that there is no better place to hire Python developers than at PyCon. We offer sponsors a place on our site to promote available positions, and we run a job fair on-site that has been a huge success. The Expo Hall is a great place to market your latest projects and to network with 2,000 eager Python developers. The value is unparalleled in the conference scene, especially after considering our flexibility to work with each and every organization. We even offer a 50% discount to organizations under 25 people. See https://us.pycon.org/2013/sponsors/whysponsor/ for more thoughts.

While we’re still finalizing the sponsorship prospectus, it will be very similar to the one we used in 2013 at https://us.pycon.org/2013/sponsors/prospectus/. We’ll share the details as soon as we complete them, and any questions can be forwarded to our Sponsorship Chair, Jesse Noller.

For 2014, PyCon will have a maximum capacity of 2,000 attendees. We’ve sold out the last two conferences and we’re expecting a third, so mark your calendars for April 9-17, 2014. Other dates to remember are our Call for Proposals in July, and we’re looking forward to opening registration in September. We’re planning for the conference schedule to be laid out in December, just in time for the holidays.

If you don’t have a passport, don’t forget that entering Canada requires one. US residents should see http://travel.state.gov/passport/ for details.

On the eve of DrupalCon Portland, we're happy to be able to get another free community video out, Installing and Using Dreditor. What's more exciting though, is that this video is part of our Community Tools workshop, and in an effort to spread Drupal community involvement further than where we can show up to run this free workshop, we're putting all of our materials and notes online for everyone to use freely, with the Community Tools curriculum.

A Workshop is Born

read more

Howdy, i’m sure most people are aware of the recent release of Moblin 2.0; a user experience for netbooks. I’m going to write a few blog posts about how the Moblin user experience is built on the awesome technologies in the GNOME platform.

So first up, let’s look at the Myzone, we’re starting here since this is the first thing I really worked on in the Moblin UX and i’ve been able to see it through from early ideas to the 2.0 and 2.1 releases.

So, deep breath, the idea behind the Myzone is to provide a springboard to things that matter to you most: your recent files and web pages you’ve visited, your upcoming events and things you need to do, things that are happening on social web services and your favourite applications.

Now then, that’s the theory, how does it work:

• Recent files: Recent file information is pulled from the GtkRecentManager and the thumbnails are pulled from the XDG thumbnail specification directory. Metadata for the file comes courtesy of gio which I presume comes from shared-mime-info. Yay. By using the GtkRecentManager for all our recent activity metadata across the platform we’re allowing legacy GNOME applications to just work. Sweet.
• Events and tasks: These are pulled from EDS using libjana, a calendaring library primarily developed by Chris Lord (of Dates fame.) A couple of months back (well, uh, March) I enhanced libjana to support tasks and thus we are able reuse the existing Tasks/Dates apps for interacting with the calendar.
• Favourite apps: Here I let the side down. I use some quite crazy custom format for doing this which frankly stinks. I’m going to try and sit down with the GNOME shell guys to see if we can come up with some better way for dealing with user originated application metadata.
• Social networking/web service integration: This comes courtesy of Mojito and librest, two projects that I and the esteemed Ross Burton have been working on. Mojito is a project that pulls in content from a variety web services into a centralised place, abstracting some of the complexity and the makes it trivial to query. librest is a library for to keep developers happy even though they’re having to deal with web services. It does this by making requests and parsing the result simple.

Previously i’d talked about how we use GNOME technologies in the Moblin Myzone. Now i’m going to talk about another component that i’m responsible for, the People Panel.

An important aspect of the Moblin user experience is about communicating with others and this panel provides quick access to do this. The core of the content is provided by an abstraction, simplification and aggregation library called Anerley. This provides a “feed” of “items” (an addressbook of people) that aggregates across the system addressbook, powered by EDS, and your IM roster, powered by Telepathy. You have small set of actions you can do on these people such as start an IM conversation / email / edit them with Contacts. The core of our IM experience is supplied by the awesome Empathy. We’ve been working with the upstream maintainers to accomodate some of the needs of Moblin into the upstream source. This included the improvements to the accounts dialog and wizard that landed for GNOME 2.28.

One of the biggest problems with the IM experience in Moblin 2.0 was that it was easy to miss when somebody was talking to you. If you were looking away when the notification popped up, whoops, it’s gone. With our switch to Mission Control 5 I was able to integrate a Telepathy Observer into Anerley and the People Panel. An Observer will be informed of channels that are requested on the system. This allows us to show ongoing conversations in the panel and by exploiting channel requests and window presentation allow the user to switch between ongoing conversations. This wouldn’t have been possible without the assistance of the nice folks in #telepathy and at Collabora: Sjoerd, Will, Jonny and countless others.

I've added epub support to Debian developers reference 3.4.10 (see /usr/share/doc/developers-reference*/*.epub), so you can read it with your favorite ebook reader like kindle, sony reader or something that NetBSD folks uses for porting ;-)

French translation: http://montrealpython.org/fr/2013/05/pycon-day-sponsors/

It's that time again! Planning for PyCon 2014 is well underway, and we're currently preparing for the launch of our new site. With the launch comes a unique opportunity: Is your organization interested in being a launch day sponsor?

PyCon 2013 launched on July 9, 2012 with 21 sponsors pledging support, leading the charge that drew over 150 organizations to pitch in to the biggest and best Python conference yet. We're planning a similar go-live date for the 2014 site, and we're building up our cadre of supporters for the April 9-17 conference taking place in Montreal, Quebec, Canada.

Your organization's support enables PyCon to do the awesome things that it does. 2013 introduced a number of new events that we've heard great feedback on, so we'd like to keep doing those things and more. For example, the inaugural Young Coders tutorial was such a hit that there are already plans around the world for user groups to replicate it, and we're looking forward to doing a PyCon 2014 rendition. Programs like Financial Aid, which saw its budget increased and then quickly doubled to reach $100,000 USD, are greatly enhanced by the giving of sponsors.

Along with benefiting the community, sponsorship of PyCon brings many benefits to its supporters. We hear it year after year that there is no better place to hire Python developers than at PyCon. We offer sponsors a place on our site to promote their open positions, and we run a job fair on-site that has been a huge success. The Expo Hall is a great place to market your latest projects and to network with 2,000 eager Python developers. The value is unparalleled in the conference scene, especially after considering our flexibility to work with each and every organization. We even offer a 50% discount to organizations under 25 people. See https://us.pycon.org/2013/sponsors/whysponsor/ for more thoughts.

While we're still finalizing the sponsorship prospectus, it will be very similar to the one we used in 2013 at https://us.pycon.org/2013/sponsors/prospectus/. We'll share the details as soon as we complete them, and any questions can be forwarded to our Sponsorship Chair, Jesse Noller.

For 2014, PyCon will have a maximum capacity of 2,000 attendees. We've sold out the last two conferences and we're expecting a third, so mark your calendars for April 9-17, 2014. Other dates to remember are our Call for Proposals in July, and we're looking forward to opening registration in September. We're planning for the conference schedule to be laid out in December, just in time for the holidays.

If you don't have a passport, don't forget that Canada requires one. US residents should see http://travel.state.gov/passport/ for details.