FLOSS Project Planets

Jonathan Brown: Generating safe markup in Drupal 8

Planet Drupal - Fri, 2014-09-19 14:29

The most insecure part of a Drupal website is typically the theme. Drupal 8 is using Twig as its template layer. This is a massive leap forward. It's no longer possible to put SQL queries in a template file!

Furthermore, Drupal 8 is now taking advantage of a security feature of Twig: autoescape. Every variable in a Twig template will be escaped if it is not marked as safe. This makes it much harder to introduce XSS vulnerabilities.

Unfortunately any HTML that your module produces will end up being double-escaped and the HTML itself will be visible instead of the browser's rendering of it. The quick and dirty way to fix this problem is to wrap your string with \Drupal\Component\Utility\SafeMarkup::set:

<?php
$output = SafeMarkup::set('<div class="my-module">' . $my_variable . '<div>');
?>

But this defeats the whole point of using autoescape. The correct approach is that all HTML created by a module should be declared in a Twig template. This means that all the variables are guaranteed to be escaped. It is also very easy to implement.

First you need to declare the template in your hook_theme():

<?php
function my_module_theme(array $existing, $type, $theme, $path) {
  return array(
    'my_module_my_template' => array(
      'template' => 'my-template',
      'variables' => array(
        'variable1' => NULL,
        'variable2' => NULL,
      ),
    ),
  );
}
?>

You then need to create a Twig template file, for example my_module/templates/my-template.html.twig:

{#
/**
* @file
* Default theme implementation for my template.
*
* Available variables
* - variable1: The first variable.
* - variable2: The second variable.
*/
#}
<div class="my-template">
  This is the first variable: <b>{{ variable1 }}</b>.
  This is the second variable: <i>{{ variable2 }}</i>.
</div>

When you need to generate your html you should use the drupal_render() function:

<?php
$render = array(
  '#theme' => 'my_module_my_template',
  '#variable1' => t("First"),
  '#variable2' => t("Second"),
);

$output = drupal_render($render);
?>

Strings returned by drupal_render() are automatically marked as safe and will not be escaped again.

Categories: FLOSS Project Planets

Glyph Lefkowitz: Ungineering

Planet Python - Fri, 2014-09-19 14:22

I am not an engineer.

I am a computer programmer. I am a software developer. I am a software author. I am a coder.

I program computers. I develop software. I write software. I code.

I’d prefer that you not refer to me as an engineer, but this is not an essay about how I’m going to heap scorn upon you if you do so. Sometimes, I myself slip and use the word “engineering” to refer to this activity that I perform. Sometimes I use the word “engineer” to refer to myself or my peers. It is, sadly, fairly conventional to refer to us as “engineers”, and avoiding this term in a context where it’s what everyone else uses is a constant challenge.

Nevertheless, I do not “engineer” software. Neither do you, because nobody has ever known enough about the process of creating software to “engineer” it.

According to dictionary.com, “engineering” is:

“the art or science of making practical application of the knowledge of pure sciences, as physics or chemistry, as in the construction of engines, bridges, buildings, mines, ships, and chemical plants.”

When writing software, we typically do not apply “knowledge of pure sciences”. Very little science is germane to the practical creation of software, and the places where it is relevant (firmware for hard disks, for example, or analytics for physical sensors) are highly rarified. The one thing that we might sometimes use called “science”, i.e. computer science, is a subdiscipline of mathematics, and not a science at all. Even computer science, though, is hardly ever brought to bear - if you’re a working programmer, what was the last project where you had to submit formal algorithmic analysis for any component of your system?

Wikipedia has a heaping helping of criticism of the terminology behind software engineering, but rather than focusing on that, let's see where Wikipedia tells us software engineering comes from in the first place:

The discipline of software engineering was created to address poor quality of software, get projects exceeding time and budget under control, and ensure that software is built systematically, rigorously, measurably, on time, on budget, and within specification. Engineering already addresses all these issues, hence the same principles used in engineering can be applied to software.

Most software projects fail; as of 2009, 44% are late, over budget, or out of specification, and an additional 24% are cancelled entirely. Only a third of projects succeed according to those criteria of being under budget, within specification, and complete.

What would that look like if another engineering discipline had that sort of hit rate? Consider civil engineering. Would you want to live in a city where almost a quarter of all the buildings were simply abandoned half-constructed, or fell down during construction? Where almost half of the buildings were missing floors, had rents in the millions of dollars, or both?

My point is not that the software industry is awful. It certainly can be, at times, but it’s not nearly as grim as the metaphor of civil engineering might suggest. Consider this: despite the statistics above, is using a computer today really like wandering through a crumbling city where a collapsing building might kill you at any moment? No! The social and economic costs of these “failures” is far lower than most process consultants would have you believe. In fact, the cause of many such “failures” is a clumsy, ham-fisted attempt to apply engineering-style budgetary and schedule constraints to a process that looks nothing whatsoever like engineering. I have to use scare quotes around “failure” because many of these projects classified as failed have actually delivered significant value. For example, if the initial specification for a project is overambitious due to lack of information about the difficulty of the tasks involved, for example – an extremely common problem at the beginning of a software project – that would still be a failure according to the metric of “within specification”, but it’s a problem with the specification and not the software.

Certain missteps notwithstanding, most of the progress in software development process improvement in the last couple of decades has been in acknowledging that it can’t really be planned very far in advance. Software vendors now have to constantly present works in progress to their customers, because the longer they go without doing that there is an increasing risk that the software will not meet the somewhat arbitrary goals for being “finished”, and may never be presented to customers at all.

The idea that we should not call ourselves “engineers” is not a new one. It is a minority view, but I’m in good company in that minority. Edsger W. Dijkstra points out that software presents what he calls “radical novelty” - it is too different from all the other types of things that have come before to try to construct it by analogy to those things.

One of the ways in which writing software is different from engineering is the matter of raw materials. Skyscrapers and bridges are made of steel and concrete, but software is made out of feelings. Physical construction projects can be made predictable because the part where creative people are creating the designs - the part of that process most analagous to software - is a small fraction of the time required to create the artifact itself.

Therefore, in order to create software you have to have an “engineering” process that puts its focus primarily upon the psychological issue of making your raw materials - the brains inside the human beings you have acquired for the purpose of software manufacturing - happy, so that they may be efficiently utilized. This is not a common feature of other engineering disciplines.

The process of managing the author’s feelings is a lot more like what an editor does when “constructing” a novel than what a foreperson does when constructing a bridge. In my mind, that is what we should be studying, and modeling, when trying to construct large and complex software systems.

Consequently, not only am I not an engineer, I do not aspire to be an engineer, either. I do not think that it is worthwhile to aspire to the standards of another entirely disparate profession.

This doesn’t mean we shouldn’t measure things, or have quality standards, or try to agree on best practices. We should, by all means, have these things, but we authors of software should construct them in ways that make sense for the specific details of the software development process.

While we are on the subject of things that we are not, I’m also not a maker. I don’t make things. We don’t talk about “building” novels, or “constructing” music, nor should we talk about “building” and “assembling” software. I like software specifically because of all the ways in which it is not like “making” stuff. Making stuff is messy, and hard, and involves making lots of mistakes.

I love how software is ethereal, and mistakes are cheap and reversible, and I don’t have any desire to make it more physical and permanent. When I hear other developers use this language to talk about software, it makes me think that they envy something about physical stuff, and wish that they were doing some kind of construction or factory-design project instead of making an application.

The way we use language affects the way we think. When we use terms like “engineer” and “builder” to describe ourselves as creators, developers, maintainers, and writers of software, we are defining our role by analogy and in reference to other, dissimilar fields.

Right now, I think I prefer the term “developer”, since the verb develop captures both the incremental creation and ongoing maintenance of software, which is so much a part of any long-term work in the field. The only disadvantage of this term seems to be that people occasionally think I do something with apartment buildings, so I am careful to always put the word “software” first.

If you work on software, whichever particular phrasing you prefer, pick one that really calls to mind what software means to you, and don’t get stuck in a tedious metaphor about building bridges or cars or factories or whatever.

To paraphrase a wise man:

I am developer, and so can you.

Categories: FLOSS Project Planets

Appnovation Technologies: Straight from the Source: Achieving Your Goals with osCaddie

Planet Drupal - Fri, 2014-09-19 14:02
See why global non-profit organization Teach For All chose our osCaddie solution var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Categories: FLOSS Project Planets

PyCharm: First PyCharm 4 Preview Build Now Available

Planet Python - Fri, 2014-09-19 13:17

It’s an exciting day for us at JetBrains PyCharm, as the first PyCharm 4 public
preview build 138.2360 is finally available for download! Head on over to the PyCharm Early Access Preview (EAP) page and have a look at the download section where you can get it for your platform right now.

As usual the PyCharm 4 preview build is available in two editions – free/open source PyCharm Community Edition and full-fledged PyCharm Professional Edition. While both of them are available for download and use at no charge, PyCharm Professional Edition has a 30-day evaluation period, which means PyCharm 3.4 Professional Edition EAP build 138.2360 comes with a 30-day time-limited license as well.

Note: The PyCharm 4 EAP build is not in the final product release stage and might contain severe bugs, so it’s supposed to be installed along with your current PyCharm installation for evaluation and checking out new features. No patch update for this EAP build will be available from within the IDE.

The PyCharm 4 preview build introduces a lot of new features, bug fixes and improvements, including a number of recently added PyCharm’s unique features as well as some features and improvements from Web and IntelliJ platform sides.

The most notable PyCharm’s unique features in this preview build are:

Behaviour-driven development (BDD) assistance

Behaviour-driven development has never been so easy and natural. With PyCharm 4 EAP we introduce the special BDD assistance giving you the full control of your textual requirements, graphical representation of the test results, and extensive and intelligent assistance on each step of the overall BDD process:

PyCharm 4 EAP now fully supports the two most popular Python tools for BDD: behave and lettuce.
PyCharm recognizes feature files, provides syntax highlighting, auto-completion, as well as navigation from specific feature statements to their definitions and back – all in a unified fashion.
Thanks to its high intelligence, PyCharm has a deep understanding of the definition steps: it shows errors and suggests automatic quick fixes, saving your time and increasing overall performance:

PyCharm and PyDev debuggers are merged

As you probably know, previously PyCharm has been using special fork of the PyDev debugger with some PyCharm specific changes and our own unique features like GEvent debugging and breakpoints at Django templates. We’re very proud that the PyCharm team is an active member of the Python community, with many team members deeply involved in different open-source projects development. So recently we decided to make one more contribution to open-sourced software and merged our debugger code with that from the original PyDev repository. Now the work on the debugger continues from both sides (PyCharm and PyDev) in a single place. The merged source code now lives here: https://github.com/fabioz/PyDev.Debugger Pull requests are greatly appreciated!

Referring objects view in PyCharm debugger

When debugging your project you can open the referring objects view for a desired object during runtime. To do so, in the debug mode right-click the object in the “Variables” window then click “Show Referring Objects”:

Jinja2 templates debugging

Now the PyCharm debugger works with Jinja2 templates. You can set breakpoints right in the editor, stop on them and perform other debugging actions the same way as in the already supported Django templates debugging mode:

To learn more about the new BDD or debugger functionality, stay tuned for further blog posts, announcements, and tutorials.

Improved Python/Django console tool window

PyCharm automatically detects which type of the console should be run depending on your project type and context. The console can be launched via the tools window menu as shown on the picture below or using the “Ctrl+ E” shortcut:

Still, there is one more cool Python console feature that was included in this build:

Now you can leave the console opened after a project run or a debug session, saving its context. In order to enable this functionality, you just need to mark the “Show command line afterwards” option in the project run/debug configurations:

Method Call hierarchy

Thanks to the PyCharm’s fantastic static code analysis capabilities, PyCharm intelligently analyses the code and builds a call hierarchy trees for method calls in different scopes:

New project creation wizard

The project creation wizard has changed a bit and now it has 2 steps:
On the first step you have to choose the project type. On the second step PyCharm shows you only relevant settings for the selected project type:

Unittest sub-tests support

Python 3.4 support is even more polished with the PyCharm`s test runner now recognizing the subTest() context manager for unittest.

As usual, PyCharm 4 will have all features of the upcoming WebStorm 9 release. WebStorm 9 preview builds are already available (read more in WebStorm blog), so here is just a short summary of what’s new available in the PyCharm 4 preview build 138.2360 from the Web side:

- Updated Live Edit feature that can now automatically update your Node.js app on any changes
- Spy-js for Node.js applications
- PhoneGap/Cordova integration
- Postfix templates for JavaScript
- Improved Editorconfig plugin
- Gulp integration
- Improved Polymer support
- Support for the latest Sass 3.4

These new features are available for installation from JetBrains plugin repository.

Apart from additional features and improvements from the Web side, PyCharm 4 gets a lot of improvements from the underlying IntelliJ Platform. The most noteworthy changes are:

  • Redesigned Settings(Preferences in OS X) dialog: settings dialog gets a cleaner interface, a more straightforward layout and a rearranged settings tree (some of the settings have been merged, and others reordered based on their frequency of use):

  • The Open action from the Welcome screen now opens single files. That means you can now edit files regardless of the projects and their configurations.

Other improvements from the IntelliJ Platform include:
- Backspace smart indent makes the Backspace key aware of your code formatting settings, so it doesn’t break your code when removing indents before caret.
- The new Code cleanup action (available via Analyze → Code Cleanup or as an option in the VCS commit dialog) applies quick-fixes in batch mode to selected files.
- The improved Find in path action
- Copy/paste selected code as HTML/RTF is now available without additional plugins.
- Better IDE startup time.
- Mercurial support improvements
- Reset Current Branch to Here action now available from the Git Log

Download PyCharm 4 preview build 138.2360 for your platform right from the project EAP page and please report any bugs and feature request to our Issue Tracker.

Develop with pleasure!
-PyCharm team

Categories: FLOSS Project Planets

Drupal core announcements: Today there are zero Drupal 8 beta blockers! Here's what's next.

Planet Drupal - Fri, 2014-09-19 13:17

As of 06:58 UTC today, September 19, there are zero Drupal 8 beta blockers. This means that, after more than nine months of focused effort, we are almost ready to release the first Drupal 8 beta!

When will Drupal 8.0.0-beta 1 be released?

Today (September 19), we have released one more Drupal 8 alpha, Drupal 8.0.0-alpha15. This alpha can be treated as a "beta release candidate". If no additional beta blockers are identified in the next 10-14 days, we will then tag the first beta! (If we do discover additional beta blockers, then we will evaluate them and adjust our timeline.)

What does beta mean?

Betas are good testing targets for developers and site builders who are comfortable reporting (and where possible, fixing) their own bugs, and who are prepared to rebuild their test sites from scratch if necessary. Beta releases are not recommended for non-technical users, nor for production websites.

See Dries' original announcement about the beta for more information on the beta and the criteria for beta blockers. The explanation of the Drupal 8 release management tags explains the differences between critical beta blockers and other issues impacted by the beta phase.

How can I help? Help stabilize the beta

The beta is an important milestone for Drupal 8. Help test the final alpha for critical and potentially beta-blocking bugs, and take extra care to avoid introducing regressions during this pre-beta window.

Beta deadline issues (complete by September 28)

This final pre-beta window is our final chance to complete beta deadline issues. As a reminder, changes to the following have a beta deadline:

  1. Non-critical changes to the core data model. (See the beta-to-beta upgrade path and data model stability policy and the beta-to-beta-upgrade path critical task for ongoing discussion of what is included in the Drupal 8 data model, how we will handle small data model additions, and when we will support a beta-to-beta upgrade path).
  2. Non-critical, backward-compatibility-breaking changes to the public APIs of the following critical subsystems:
    • The Configuration system
    • The Entity Field API
    • The Plugin API
    • The Menu and Routing APIs
  3. Other broad, non-critical changes that significantly break backward compatibility, at core maintainer discretion.

Beta deadline issues can be committed up until Sunday, September 28, after which there will be a freeze to ensure stability. If you have questions or concerns about completing a particular change, speak to a core maintainer about it soon.

If you know of issues that would introduce any of these changes, add the "beta deadline" issue tag so that contributors can find and help complete them before the beta. The following issues are particular priorities:

(Also see the full queue of known beta deadline issues.)

Keep in mind that API and schema additions may still be made during the beta phase, at core maintainer discretion. Limited API and data model changes will also happen during the beta phase, though core maintainers will try to isolate these changes to non-fundamental APIs or critical bug fixes. (See the ongoing beta-to-beta-upgrade path discussion.)

Beta target issues

"Beta target" issues are issues that we hope to complete early during the beta phase, but can still be added to Beta 2 or later. These are the next priority after important beta deadline issues. We especially need to work on:

(Also see the full queue of known beta target issues).

Thank you!

Many thanks to the 234 contributors who have helped resolve our 177 beta blockers in Drupal 8, and to the incredibly dedicated Drupal 8 branch maintainers. Your focus and effort is helping us build a solid Drupal 8 beta and, going forward, a better release.

Categories: FLOSS Project Planets

Simple by Default, Powerful When Needed

Planet KDE - Fri, 2014-09-19 12:36

KDE (back when it was still the name of the desktop environment) and our applications historically stood for powerful features and great flexibility and customizeability. This is what our users love about our software, this is why they choose Plasma and KDE software instead of one of the other Free desktop offerings. And it is also something they would fight tooth and nail for if we wanted to take it away (as many a KDE maintainer who dared to remove a feature he thought was unnecessary can tell).

On the other hand, this power and flexibility at times leads to user interfaces that intimidate especially new users if they expose all the features they have to users at once, leading them to avoid our applications altogether. This keeps them from ever experiencing the power which they might enjoy later on, as they use an application for more advanced tasks.

With KDE4 (back then, Plasma as a brand was not born yet), the aim was to keep the power, but do away with the scariness, as the KDE4 Vision states:

“Anything that makes Linux interesting for technical users (shells, compilation, drivers, minute user settings) will be available; not as the default way of doing things, but at the user’s discretion.”

In the design vision and principles section of the KDE HIG, we condensed and evolved this goal into a simple guiding principle:

Simple by default, powerful when needed.

How do we reach that goal?

As the first step, it is necessary to define the target audience and use scenario for an application. Only if we know that, we can define which goals users should be able to reach using the application.

The next step is to define for each goal how likely our target users in the target scenario are to actually have that goal, and how regularly. As an example, when we planned KMail Active (aimed at tablet computers) a year ago, we categorized the tasks we wanted to support in three groups: common, uncommon, and rare.
Only the common actions would be accessible directly in the main user interface. Since the usage scenario we had in mind for KMail Active was “Quickly checking up on new mails on the go or at home on the sofa and occasionally reply”, only those functions relevant to that scenario were planned to be placed in the main UI.
This is how we achieved the “Simple by default goal”:

Early-stage mockup for an email client for tablet computers, to be used in Plasma Active, applying the “Simple by default. Powerful when needed” philosophy.

We optimized KMail Active for users who would rather use KMail Desktop to actually organize their emails by sorting them into folders, or try to retrieve old emails in any folder. However, we recognized that sometimes users may need to retrieve an email from some otherwise rarely used folder or tag or move an email to a certain folder in order to find it more easily later, but don’t have access to a desktop or laptop PC. Therefore a UI to browse through the whole folder hierarchy and the tags (not mocked-up yet) was included in the design, though only visible if users scrolled the view to the left.

The same goes for writing new emails. The default UI for that won’t include things like HTML formatting or adding attachments (since writing longer and more complex emails is not convenient on a device without a keyboard, and users are less likely to have documents they want to send to people on their tablet), but they, too are only presented on demand, not by default. This is the “powerful when needed” part.

This philosophy will guide the designs provided by the VDG, so you will see more examples coming up, soon!

UPDATE: As I’ve seen in some discussions of my post on the Internet (not the comments here) that people apparently thought the screenshot represented the next KMail desktop UI, I’ve updated the screenshot and the caption to make clear what it is.

UPDATE2: Now that this post has become quite popular (2.394 unique visitors so far today!), I felt the need to make clear that – as always with Free Software – all this is a team effort. The original version of the design principles Wiki page was written by Andrew Lake, the user stories for KMail Active were co-written with Heiko Tietze and Michael Bohlender, the design of the mockup was done by Michael Bohlender with my help, and Michael also contributed to the philosophy tagline, by replacing “complex” with “powerful”.


Filed under: KDE, User Experience
Categories: FLOSS Project Planets

Bluespark Labs: Cleaning our repository history

Planet Drupal - Fri, 2014-09-19 11:49

In our daily work we all make mistakes in our git commits. Sometimes this errors can easily be repaired just by reverting our commits. But if we are working in a public repository and we have accidentally pushed some sensitive information, we now have a problem.

That sensitive information is in our repository history and anybody who has the enough time to explore can gain access to that. Our clients or even ourselves are now dealing with a privacy issue.

We can always try to repair that commit in our local environment and push our code again using the --force parameter. But we know, when you do that, a kitten dies. And if your team members already pushed something, everything in the repository will be messed up.

So the best option is to try and fix this in a more elegant way that allow us to erase all the traces of our mistake, but preserves repository integrity.

Git provides the filter-branch command, but sometimes this powerful tool becomes too complicated and slow. In trying to find an easier way to do it, finally came across the BFG Repo-Cleaner.

This tool is an alternative to git filter-branch that provides a faster and easier way to clean git repositories. It is written in Java, so you need to make sure you have JRE 6.0 or above installed. To clean your repository you only have to follow the steps below:

Clone your repository using the --mirror option. Beforehand, you should repair manually your mistakes in the repository.

1 $ git clone --mirror git://example.com/my-repo.git

Now, download BFG and execute it against your cloned repository.
1 $ java -jar bfg.jar --strip-blobs-bigger-than&nbsp;1M&nbsp;my-repo.git
This step will remove all the blobs bigger than 1MB from your repository.

Once the index has been cleaned, examine your repository's history and then use the standard git gc command to strip out the unwanted dirty data, which Git will now recognise as surplus to requirements:
1 2 3 $ cd my-repo.git $ git reflog expire --expire=now --all $ git gc --prune=now --aggressive

Finally, once you're happy with the updated state of your repo, push it back up
1 $ git push

If everything went well, your repository won't include any of the accidentally committed files.

Here you have some common examples to use with Drupal:
Delete all files named 'id_rsa' or 'id_dsa' :
1 $ java -jar bfg.jar --delete-files id_{dsa,rsa} &nbsp;my-repo.git

Delete database dumps:
1 $ java -jar bfg.jar --delete-files *{mysql,mysql.gz}

Delete files folder:
1 $ java -jar bfg.jar --delete-folders files

We have to remark that BFG assumes that you have repaired your repository before executing it. You need to make sure your current commits are clean. This protects your current work and gives you peace of mind knowing that the BFG is only changing your repo history, not meddling with the current files of your project.

Finally, here you have some useful related links:

Tags: Drupal Planet
Categories: FLOSS Project Planets

Recent developments in Dolphin: Improvements in Dolphin 4.14, and change of maintainership

Planet KDE - Fri, 2014-09-19 11:20

 

Recently, Dolphin 4.14 has been released, and in this post, I will tell you about the improvements that are included in this release. This is my last “recent developments in Dolphin” post – I have stepped down as maintainer recently.

Maintaining Dolphin has been a very pleasant and rewarding experience. It went a lot better than I had expected when I took over from Peter a bit more than 2 years ago: Dolphin has been improved in many ways, and I am grateful to everyone who helped to make this possible.

I cannot continue to spend as much time on Dolphin as I did during the past two years, so I have asked Emmanuel Pescosta if he is willing to take over. I am very happy that he accepted because he has made an impressive number of contributions to Dolphin, and I am sure that he will keep Dolphin in good shape and improve it further.

This is not a “good bye” post though – I am still planning to contribute to KDE in general and Dolphin in particular in the future.

Dolphin 4.14.1
  • Bug 323077: Hide an error message (which is shown above the view) before showing a new one. See git commit e7ef1cb8, review request 119401.
  • Bug 338549: Fix the problem that the context menu and the Delete key do not work after restoring a session with split views. See git commit 13efd595, review request 119961.
  • Bug 333078: Make it possible to open archives via the command line. See git commit 421e7ea4, review request 119877.
Dolphin 4.14.0
  • Bug 334271: Improve the drawing of the status bar widgets on high-DPI displays. See git commit 1b6ce8a9, review request 119701.
  • Bug 332629: Use a shorter icon text for the “Previous” and “Next” toolbar buttons. See git commit 03f7f20b, review request 117794.
  • Bug 327708: Make sure that the “free space” information, which can be shown in the status bar, updated in all visible views. See git commit de197075, review request 118208.
  • Bug 337104: Fix wrong text eliding in some corner cases. See git commit a203c271, review request 119546.
  • A small visual improvement in the Places Panel, which was motivated by a post in our forum and a comment on a Visual Design Group report: Do not underline the current item (or draw a dotted rectangle around it, depending on the style). The “selected item” highlighting is sufficient because the selected item is always the current one in the panel. See git commit d329e0ed, review request 119019.
  • Bug 304643: Include not only the item text, but also the icon in the selection rectangle in Compact/Details View and the Places Panel. Moreover, do not tint the icon of the selected item. See git commit 1f69714a, review request 119018 (also for information why removing the icon tinting in Icons View is not so easy).
  • Fix a runtime warning (“QPixmap::scaled: Pixmap is a null pixmap”) that was caused by the Information Panel on startup. See git commit b28f9628, review request 119553.
  • Bug 329377: Fix incorrect selection of items when expanding a folder in Details View in some corner cases. See git commit 1c9a92da, review request 119703.
  • Start a refactoring of the rather huge DolphinMainWindow class. This will make bug fixes and other maintenance efforts easier in the future. See git commits 58ac6a46, 6a98d833 and review requests 118805, 118964.
  • Make opening URLs via the command line more efficient by avoiding that a tab is created for the Home URL and destroyed immediately. See git commit e4705292, review request 118966.
  • Save memory and CPU cycles by not storing the item width (in Icons View) or the item height (in Compact and Details View) for every item. Since it is the same for every item in the view, it is sufficient to store it once. See git commit d8c078eb, review request 118454.
The frameworks branch

Alexander Richardson ported the entire code base to Qt 5 and the KDE Frameworks – many thanks for that! If you want to test it, use the “frameworks” branch from our git repository, or check if your distribution provides packages that are made from this branch. It works quite nicely already, but it still has some rough edges. If you find some, please file a bug report, or even better, dig into the code, try to figure out what’s going wrong, and submit a patch to Review Board.

Thanks to everyone who helped to make the improvements in Dolphin 4.14 possible, and also to those who contributed the first patches to the frameworks branch: Alexander Richardson, Alex Merry, Arjun Ak, Christoph Feck, Christophe Giboudeaux, David Faure, Emmanuel Pescosta, Frederik Gladhorn, Hrvoje Senjan, Kai Uwe Broulik, Laurent Montel, Luca Beltrame, Lukáš Tinkl, Mathieu Tarral, Michael Reeves, Renato Atilio, and Scarlett Clark.


Categories: FLOSS Project Planets

FSF Events: LibrePlanet 2015: Free Software Everywhere (Cambridge, MA)

GNU Planet! - Fri, 2014-09-19 11:12

This year, the theme of LibrePlanet is "Free Software Everywhere." We're looking for talks that touch on the many places and ways that free software is used around the world, as well as ways to make free software ubiquitous. Think "where" in the broadest sense of the word--it's not just geography-based talks we're after. What are some contexts where free software is thriving, and some others where it needs a push? How have you worked to gain a foothold for free software in your company or community? And what about free software on all of the myriad pieces of hardware we use, including laptops, phones, tablets, and even coffee makers? At LibrePlanet 2015, we're taking software freedom around the world, to outer space, and through all kinds of industries, governments, organizations, fields of study, and communities.

Please fill out our contact form, so that we can contact you about future events in and around the Boston area.

Categories: FLOSS Project Planets

Akademy Days 2014

Planet KDE - Fri, 2014-09-19 10:55

This was my first akademy and it meant a lot to me   I would love to share the snaps I had taken before I write down further. Here is the link from flickr(https://www.flickr.com/photos/sujith-h/sets/72157646981723648/). It was my immense pleasure to meet many people around the conference. I remember the first day where I was so shy to talk to people gathered around at RedHat office in the evening. And Adriaan de Groot helped me out :).

First two days were amazing with with good enlightening talks ( as I wont be writing too much about that because they are already described in dot(https://dot.kde.org/2014/09/11/akademy-wednesday-and-thursday-wrapup, https://dot.kde.org/2014/09/10/akademy-tuesday-wrapup, https://dot.kde.org/2014/09/08/akademy-2014-day-2-talks and https://dot.kde.org/2014/09/08/akademy-award-winners-2014)). Then on the BoF’s started. I got an idea to implement something new for PlasmaMediacenter. Once implemented and changes pushed I will share the blog post for the same.

I thank a lot to e.V and sponsors for this good event.

Categories: FLOSS Project Planets

Bad Voltage Season 1 Episode 25: On a Stick With No Fripperies

LinuxPlanet - Fri, 2014-09-19 10:00

Bryan Lunduke, Jono Bacon, Stuart Langridge and myself present Bad Voltage, in which we discuss the wonderful products of the Jimmy Dean sausage empire, have unexpected bouts of poetry, lunch each other with frippery, and also discuss:

  • The final installment of the Bad Voltage Reverso Debate, which, due to a tie in the last installment, results in an awkward three-way. Jeremy and Jono are donating to Charity:Water as a result, and we are looking to raise $1500 from the Bad Voltage community to help – go and donate! (2.30)
  • Stuart reviews the EZCast and evaluates whether he can use it to rock the conference circuit on his phone (21.58)
  • We crown the winner of the Bad Voltage Mashed Voltage competition who wins a piece of tat from each member of the team. Go and listen to all the entries (33.27)
  • We cover work/life balance and discuss where the burden of responsibility is between the employer and employee in ensuring people have the balance right (39.32)

Listen to 1×25: On a Stick With No Fripperies

As mentioned here, Bad Voltage is a new project I’m proud to be a part of. From the Bad Voltage site: Every two weeks Bad Voltage delivers an amusing take on technology, Open Source, politics, music, and anything else we think is interesting, as well as interviews and reviews. Do note that Bad Voltage is in no way related to LinuxQuestions.org, and unlike LQ it will be decidedly NSFW. That said, head over to the Bad Voltage website, take a listen and let us know what you think.

–jeremy


Categories: FLOSS Project Planets

FSF Events: Software Freedom Day celebration (Montreal, Canada)

GNU Planet! - Fri, 2014-09-19 09:50

FACIL, pour l'appropriation collective de l'informatique libre (FACIL), a non-profit organization focused on the adoption, usage and democratisation of software freedom, invites FSF members and friends to the Software Freedom Day celebration in Quebec. The celebration will also open the Semaine québécoise de l'informatique libre (SQIL), which will run from September 20th to 28th.

The event est free and everyone is encouraged to attend.

Please fill out our contact form, so that we can contact you about future events in and around Montreal.

Categories: FLOSS Project Planets

FSF Events: Semaine Quebecoise de l'Informatique Libre (Montreal, Canada)

GNU Planet! - Fri, 2014-09-19 09:49

FACIL, pour l'appropriation collective de l'informatique libre (FACIL), a non-profit organization focused on the adoption, usage and democratisation of software freedom, invites FSF members and friends to the Software Freedom Day celebration in Quebec. The celebration will open the Semaine québécoise de l'informatique libre (SQIL), which will run from September 20th to 28th.

The event est free and everyone is encouraged to attend.

Please fill out our contact form, so that we can contact you about future events in and around Montreal.

Categories: FLOSS Project Planets

PyCharm: Feature Spotlight: Deployment with PyCharm

Planet Python - Fri, 2014-09-19 09:08

Happy Friday, everyone!

I’d like to highlight a very handy feature of PyCharm called Deployment support in our spotlight this week:

When developing some Python or Web applications, chances are at one point we will be deploying them. During development we may want to deploy our application to a testing/staging server, to a VM or a Vagrant box. And once release day is there we want to make sure our carefully crafted code makes it to production.

PyCharm shines here again, as it supports code deployment to remote hosts. Read the Deployment in PyCharm tutorial to learn how to easily set up mappings, browse files on a remote machine, upload and synchronize your code, compare local and remote versions of your files and configure automatic synchronization.

See you next week!
-Dmitry

Categories: FLOSS Project Planets

Code Karate: Drupal 7 Honeypot Module

Planet Drupal - Fri, 2014-09-19 08:48
Episode Number: 169

In this tutorial you will learn about the Honeypot module. The Honeypot modules is a SPAM prevention module that uses a hidden form field to catch SPAM bots from posting onto your site. This tutorial shows you how to configure the module to work on various forms on your site.

Tags: DrupalFormsWebformDrupal 7Drupal PlanetSpam Prevention
Categories: FLOSS Project Planets

Nick Kew: Faintheart

Planet Apache - Fri, 2014-09-19 08:13

Wee, sleekit, cow’rin, tim’rous beastie,
O, what a panic’s in thy breastie!

What a letdown, Jock.  Your poet must be spinning in his grave.


Categories: FLOSS Project Planets

Lennart Regebro: A script is not configuration.

Planet Python - Fri, 2014-09-19 08:11

I’ve been looking into Ansible lately, and have had some problems in explaining what I think is wrong with Ansible, so this blog post is an attempt to do that, by comparing it with Buildout. This may seem a bit strange, since they don’t really do the same thing, but I think it will make sense in the end. So hang in there.

Ansible

Ansible calls itself “software automation”, and this is correct, but it’s often presented as an SCM system, but in my opinion it is not. And the reason for this is that Ansible is based around writing scripts. Because these scripts are written in YAML, they superficially look like configuration but that is misleading. Ansible calls these YAML files “playbooks” which again indicates what you do with them: You play them. They have a start and finish, and then perform a set of actions, in the order that the actions are defined in the playbook. The actions are often of the form “ensure that software X is installed” or “make sure that the file Y contains the line Z”. But it doesn’t change the fact that they are actions performed in the order written in the files. Therefore these files are scripts, and not configuration. Configuration does not have a specific order, configuration you first parse, and then you access the configuration data arbitrarily. This is not what Ansible playbooks does.

And that’s fine. It’s not criticism against Ansible per se. Ansible mainly calls itself a system for automation. And it is, just like any sort of script files. Bash scripts are also designed for automation. Ansible just has a very complicated (as opposed to complex) script language. Thanks to the choice of YAML the language is very restricted and often tricky to use as you end up having to fight the syntax by a very liberal and exact application of quote characters.

However, they do state on their website that “Ansible features an state-driven resource model that describes the desired state of computer systems and services, not the paths to get them to this state. ” And that is really only partly true. If you only use modules that check for state, it is true for a reasonable definition of “True”. But a lot of the modules shipped with Ansible doesn’t do that. And more importantly, the state is not defined in configuration, the state is defined in a script. This leads to limitations, which we will talk about later.

You can add new commands to Ansible by writing modules. They can be written in any language, which sounds like a neat idea, but it means that the API for a module is passing in JSON data on stdin an returning it on stdout. This makes debugging painful, and it means writing new modules a pain. In addition to that, to write Python modules you have to add a specific line at the end of the file with a “star import”, that breaks PEP8 and also confuses some syntax aware Python editors.

Ansible also recommends a specific directory layout, with several folders, who all have a file called main.yml. That means your editor quickly ends up having a whole lot of main.yml open, and that gets confusing. My good friend Jörgen Modin called that kind of layout “A conspiracy on the hard disk” in reference to using Zope Toolkit style programming which does the same with it’s configure.zcml files. A file name should reflect what is in it, not what role it plays (unless that role is unique within one project).

For SCM you also need to have several layers of orthogonal modularity. You need to be able to define up the installation of for example MySQL, and then you need to define up what software should go onto each machine. Ansible can do this, although confusingly most people tend to use what Ansible calls “roles” to define up one component, and then you use the groups in the inventory file as roles. But that’s just naming, you’ll get used to that.

Buildout

Buildout calls itself a “software build system” and that’s not incorrect, but it makes it sound like it’s competing with make and scons, and it does not. In my opinion, Buildout is closer to being a Software Configuration Management system than a build system. I would call it a Environment Configuration System as it’s mainly designed to set up development environments, although it can also be used to deploy software. It’s main shortfall to being a proper SCM is that it lacks modules to do common SCM tasks, such as installing system packages with yum and apt, and more problematically, it lacks support for running some bits, like for example yum and apt, as a superuser.

Buildout does not have any support for remote deployment, so you need to use a separate program like Fabric to run Buildout remotely.

Just like Ansible has modules you can use to create new commands, Buildout has recipes. I Ansible they can be written in any language, in Buildout they have to be written in Python. This perhaps lessens the appear to some people, but I do think the benefits are worth it. A Buildout recipe is just a Python module, like any other, and they can be made available on the Python Cheese Shop, in which case Buildout will download and install them when you run it.

Configuration, not scripting

The most important thing about Buildout for the purposes of this blog is that Buildout is configured entirely with configuration files, more specifically of the ConfigParser variety. INI-files in general have the benefit of being designed for configuration, and it’s extremely minimalist syntax means it never gets in the way. Buildout of course has to extend the syntax by allowing variable substitution, but that is also all it does. Everything written in the configuration is also a variable and can be used, so you only need to define one piece of information once.

It also means that a part of a Buildout configuration only needs to be run once, if it succeeds. It then has set up the configuration correctly, and subsequent runs can skip the parts that has succeeded, unless the configuration changes. It also means that it is, at least in theory, possible to write uninstallers, as you can record the state before the run.

The choice of INI-style syntax also means there is no inherent execution order to the configuration. The configuration instead is split up into what Buildout calls “parts”, each part executed by a recipe given in the part. Here are two examples of parts. The first one will download, compile and install nginx locally (in the buildout directory). The second will generate an nginx configuration file from a template.

[nginx] recipe = zc.recipe.cmmi url = http://html-xslt.googlecode.com/files/nginx-0.7.67-html-xslt-4.tar.gz # The SSI bug was fixed in nginx-0.7.65-html-xslt-2.tar.gz extra_options =     --conf-path=${buildout:directory}/etc/nginx.conf     --sbin-path=${buildout:directory}/bin     --error-log-path=${buildout:directory}/var/log/nginx-error.log     --http-log-path=${buildout:directory}/var/log/nginx-access.log     --pid-path=${buildout:directory}/var/nginx.pid     --lock-path=${buildout:directory}/var/nginx.lock [nginx.conf] recipe = collective.recipe.template port = 8000 root = ${buildout:directory}/examples input = ${buildout:directory}/templates/nginx.conf.in output = ${buildout:directory}/etc/nginx.conf

What makes this configuration and not a script is that none of this is executed unless the part is listed in a separate configuration:

[buildout] parts = nginx nginx.conf

Buildout configuration files can also extend other files. So if we save the above in a file called base.cfg, we can then create another configuration file:

[buildout] extends = base.cfg [nginx.conf] port = 8080

The only difference between the base.cfg and this file is that nginx will run on another port. This makes it easy for me to checkout a development environment and then make my own configuration file that just overrides the bits I need to change. Because it’s all configuration. With Ansible I would have to make the port into a variable and pass a new value in when I run Ansible. And that means that when writing Ansible playbooks, to make them proper configuration management and not scripts, everything must be a variable. Buildout avoids that issue by not having the intermediary step of Playbooks, but just having recipes, and configuration.

With buildout your configuration can also extend another configuration file, and add, skip or insert parts as you like.

[buildout] extends = base.cfg parts = nginx.config loadbalancer nginx [loadbalancer] ...

Each part remains the same, but the order is different and there is a new one in the middle. In general, because all configuration is parsed and gathered before the parts are run, it doesn’t matter much which order you run them in, but in some cases they of course do. If you are going to not just configure software, but also start it, obviously you have to install and configure it first, to take an obvious example.

There is also a special syntax for adding and removing values from a configuration like the parts-definition:

[buildout] parts += newpart1 newpart2 develop -= foo.bar A Buildout example

Buildout is often used to set up both development, staging and production environments. I have an example where I have a base.cfg that only installs the Plone CMS. I then have a production.cfg which also sets up load balancing and caching, a supervisord to run the services, a cronjob to start the services on reboot, and cronjobs to do backups and database maintenance. My staging.cfg extends the production configuration only to change the ports, so that I can run the staging server on the same machine as the production server. The development.cfg also just extends base.cfg, so you don’t get any of the production services, but it instead adds loads of development tools. Lastly there is a version.cfg which contains version numbers for everything to be installed, so you know that if you set up a local environment to test a problem, you are using the same software as production.

If you were aiming to deploy this onto several servers, and have the database on one server and caching and loadbalancing on one, and the CMS instances on separate servers, then you would make a configuration file per server-type, and use that.

Buildout extensions

Buildout has a final level of indirection, it has extensions. Examples of extensions that are available are buildout.dumppickedversions (although it’s now a part of Buildout itself) that would list all Python packages that you has not given a specific version number for. Another is called mr.developer, which gives you commands to make sure that the Python packages that you are working on are all synced to the versioning system. It can even allow you to switch between the latest release and a checked out development version of a Python package, which is really neat.

Perhaps it would possible to make an extension which will allow you to run some Buildout parts as root and other as a normal used, and I’m willing to give implementing it a try, but I’m a bit busy at the moment, so it will have to wait. And if you can’t write an extension like that, adding that feature should be relatively easy. And with that feature, I would be prepared to call Buildout a Software Configuration Management system. It may be originally developed to manage only development environments, but it has proven itself capable of much more, and it certainly has done the most important design decisions in SCM correct. Hopefully the above text will clarify why.


Filed under: python Tagged: ansible, buildout, scm, software configuration management, zc.buildout
Categories: FLOSS Project Planets

Ralph Heinkel: EuroPython 2014 pyRserve-slides now available online

Planet Python - Fri, 2014-09-19 07:50

After our well-attended Python Meetup last Wednesday in Heidelberg about "Connecting Python to other programming languages for scientific computing" I had been approached to publish the slides of my pyRserve talk (which has been the same as the one I've given at EuroPython in Berlin, for those who are interested). These are now online, so feel free to download them.

Categories: FLOSS Project Planets

Intermediate results of the icon tests: Humanity

Planet KDE - Fri, 2014-09-19 07:06

With a series of icon tests we currently study effects on the usability of icon design. This article however does not focus on these general design effects but presents findings specific to the Humanity icon set.

Keep on reading: Intermediate results of the icon tests: Humanity

Categories: FLOSS Project Planets
Syndicate content