I work on SE Linux to improve security for all computer users. I think that my work has gone reasonably well in that regard in terms of directly improving security of computers and helping developers find and fix certain types of security flaws in apps. But a large part of the security problems we have at the moment are related to subversion of Internet infrastructure. The Tor project is a significant step towards addressing such problems. So to achieve my goals in improving computer security I have to support the Tor project. So I decided to put my latest SE Linux Play Machine online as a Tor hidden service. There is no real need for it to be hidden (for the record it’s in my bedroom), but it’s a learning experience for me and for everyone who logs in.
A Play Machine is what I call a system with root as the guest account with only SE Linux to restrict access.Running a Hidden Service
A Hidden Service in TOR is just a cryptographically protected address that forwards to a regular TCP port. It’s not difficult to setup and the Tor project has good documentation . For Debian the file to edit is /etc/tor/torrc.
I added the following 3 lines to my torrc to create a hidden service for SSH. I forwarded port 80 for test purposes because web browsers are easier to configure for SOCKS proxying than ssh.
HiddenServicePort 22 192.168.0.2:22
HiddenServicePort 80 192.168.0.2:22
Generally when setting up a hidden service you want to avoid using an IP address that gives anything away. So it’s a good idea to run a hidden service on a virtual machine that is well isolated from any public network. My Play machine is hidden in that manner not for secrecy but to prevent it being used for attacking other systems.SSH over Tor
Howtoforge has a good article on setting up SSH with Tor . That has everything you need for setting up Tor for a regular ssh connection, but the tor-resolve program only works for connecting to services on the public Internet. By design the .onion addresses used by Hidden Services have no mapping to anything that reswemble IP addresses and tor-resolve breaks it. I believe that the fact that tor-resolve breaks thins in this situation is a bug, I have filed Debian bug report #776454 requesting that tor-resolve allow such things to just work .
ProxyCommand connect -5 -S localhost:9050 %h %p
I use the above ssh configuration (which can go in ~/.ssh/config or /etc/ssh/ssh_config) to tell the ssh client how to deal with .onion addresses. I also had to install the connect-proxy package which provides the connect program.
The authenticity of host ‘zp7zwyd5t3aju57m.onion ()
ECDSA key fingerprint is 3c:17:2f:7b:e2:f6:c0:c2:66:f5:c9:ab:4e:02:45:74.
Are you sure you want to continue connecting (yes/no)?
I now get the above message when I connect, the ssh developers have dealt with connecting via a proxy that doesn’t have an IP address.
-  https://www.torproject.org/docs/tor-hidden-service.html.en
-  https://www.howtoforge.com/anonymous-ssh-sessions-with-tor
-  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776454
-  http://doc.coker.com.au/computers/se-linux-play-machine/
We’ve been experimenting with monthly team sprints at ThinkShout over the last year with varied levels of structure and outcomes. This month, we decided to take a step back, reevaluate our goals, and reimagine our sprint process. And, we moved it to a Thursday. A bow-tie Thursday.
Previously, these sprints were loosely structured around a topic or technology, such as Twig in Drupal 8. Suffice it to say, they were a lot of fun and very exploratory, but they weren’t the most engaging for everyone on the team. This time around, we decided to collaborate on a single initiative - in this instance, a product - that would benefit from the skills and perspectives of everyone in the company. Consequently, we decided to rally around RedHen Raiser, our new peer-to-peer fundraising distribution for Drupal.Introducing RedHen Raiser
RedHen Raiser is designed for building peer-to-peer fundraising websites, like the sites you see for marathons and walks, where a fundraising campaign is made up of myriad individual and team pages, and can be customized by the participants for fundraising amongst their respective communities, while remaining connected to the larger campaign.
Easy Campaign creation so site visitors can join right away by creating their own Team or Individual fundraisers.
A beautiful, consistent fundraising experience that is based on inherited display values from the larger Campaign.
Goal progress widgets including thermometers, leaderboards, etc.
Mini-blogs for Campaigns and Fundraisers via Update content type.
Ability to create and maintain different pages for different fundraisers with a single account.
Automated start and end dates.
Commerce-readiness - just add your payment method and go!
Single-page donation forms via RedHen Donation.
Built using established modules with simple UI (Views, RedHen, Context, etc) for easy customization.
It’s ThinkShout’s latest offering in a suite of nonprofit engagement building blocks that we’ve been developing, and was initially developed for the Capital Area Food Bank of Washington, DC. RedHen Raiser competes feature for feature with top software as a service (SaaS) peer-to-peer fundraising platforms, such as TeamRaiser, CauseVox and Razoo.
As a result of our work with this client, we were able to release a very rudimentary version of RedHen Raiser on Drupal.org that would provide a basic starting point to other developers interested in building a peer-to-peer fundraising tool. The product is also a huge win for CAFB of DC, simply because they were able to reap a huge dividend on their initial investment by getting these improvements for free.Involving the Full Team in One Sprint
As an open source product, RedHen Raiser presented us with some interesting opportunities to engage more than just our engineers in the sprint process, and it certainly needed a lot of love on a lot of fronts. Leveraging the different interests and expertise of our 18-person company, we split into five teams:
Dev Ops - this team focused on deployment infrastructure, build processes, and automated testing;
Bug Fix & Feature Dev - team members spent the sprint day working on the development backlog;
UX - the User Experience team worked ahead of the feature development team to identify and sketch out new features and enhancements;
QA - the Quality Assurance team was made up of our project managers acting as "product owners;"
Community Engagement - this team, consisting of our sales, marketing, and operations staff, was tasked with documenting the sprint and sharing our contributions with the wider Drupal and nonprofit technology communities.
It’s worth noting that the quality assurance team and the community engagement team came together for the first half of the sprint for an in-depth training on the Drupal contributed modules and components underlying RedHen Raiser. Ironically, we often get so busy building these sorts of tools for our clients that we don’t stop to educate our own "non-developer" team members on how stuff works. By taking this time to dive into the nitty gritty with our project managers, marketing and operations folks, we create better advocates for these solutions and help ensure that everyone in the company feels like contributor to our success.Planning for the Sprint
As ThinkShout has grown, the need for sprint planning has grown with it. Back when we first started these sprints, we could fit our entire team around a single table (covered in pizza boxes and beer) and call out with development tickets we each needed help with.
Now, with a team of 18 working together from 11am to 5pm, these sprints take a bit more planning - to say nothing of balancing the opportunity cost of investing a collective 108 hours of non-client work into a single week. To keep things running smoothly, we’ve taken a more project-planning-esque approach to our sprint days:
Scheduling in advance: The date and time of the sprint is scheduled a month in advance. We used to just stick with the last Friday of the month, but found that this sometimes excluded certain team members on deadlines or vacation. Now, we coordinate a bit more tightly to help ensure participation of as many team members as possible.
Laser focus: the focus of the sprint is announced to the team three weeks in advance. This gives the team time to think about stuff they want to work on, and add to the feature backlog in the weeks coming up to the sprint.
Pre-sprint planning meetings: The department leads meet a week before the sprint to form teams and structure the sprint agenda, and prioritize the development/feature backlog two days in advance of the sprint.
Pre-sprint presentations: The week before the sprint, we do a short, company-wide presentation on the sprint topic at our weekly staff lunch. This helps energize the team and sparks knowledge sharing in the lead up to the sprint day.
Formally "opening" and “closing” the sprint day: As our sprint commences, we kick things off with a quick, all-staff scrum. More importantly, we pull the team back together at the end of the day for each sprint team to present (and celebrate!) what they’ve completed.
So what does it all mean? This new approach to our team sprints resulted in just shy of 100 commits on RedHen Raiser and the underlying modules that power the distribution. We published a new release of RedHen Raiser, RedHen Donation and the RedHen Campaign modules - as well as a release of our base RedHen CRM suite.
One of the biggest wins to come out of the sprint are automated tests powered by Behat. Tests are triggered with every commit to GitHub and run on Travis CI. At this point, test coverage is a bit limited, but the foundation has been laid for complete test coverage for RedHen Raiser, a critical factor when organizations are evaluating which software to use.
To top it off, we cleaned up a few RedHen project pages on Drupal.org and began working on a RedHen-specfic QA testing plan. We also reached out to the RedHen open source community to let them know what we were up to and how folks can continue to get involved. Most of all, we are proud to say that this effort is a huge contribution to the nonprofit tech community, in that it provides major improvements to a powerful tool that can be leveraged for free - and has the documentation to support it!
All in all, the ThinkShout team came together in a big way, and accomplished much more than we could have if we had remained siloed in our approach. We had a lot of fun, drank some beer, ate some good food, and got to collaborate as a whole team on something really cool. We’re really looking forward to the next one!
This is an old laptop, with AMD E-300 processor, 6 GB RAM, Radeon HD 6310 VGA and Atheros AR9485 wireless network adapter.
It was running Windows 7 (preinstalled). The hard disk failed, and I put the hard disk of another laptop (a broken Acer Aspire One D255) on it. Surprisingly, the Windows 7 on it booted (after some self-configuration that took quite long), but it was a Windows 7 Home 32bits, so it was only recognizing 4 GB RAM. That was the perfect excuse to convince my husband to install Debian in the laptop and begin his transition to a free OS. Yay!
I installed Debian Jessie from scratch last summer. Everything went well (the installer went fine, 8 months before than its RC1 release, congrats Debian-boot team!).
I needed the non-free radeon driver for the graphical display :/
I have problems to watch high quality videos, in every player that I tried (VLC, Totem, mplayer) the audio and video are not synced, and video sometimes freezes. I’m almost sure that the problem is what mplayer says: “Your system is too SLOW to play this!”.
I tried to install the ATI non-free driver for better performance, but after successfully install it and reboot, GNOME was not starting (I got a black screen, no gdm greeting me). I could log in tty2, though. I don’t know if I did something wrong, how to solve the problem, and I don’t wanted to waste time, so I uninstalled it and returned to the non-free firmware that goes to the Linux kernel. For now, when I need to watch a video that gives those problems, I upload the file to my GNU MediaGoblin site, or use WinFF to reduce size/quality.Overall impression
Fine! Both my husband and me are very happy.
The installation went really well.
I’m not a GNOME expert user but I find it easy, intuitive, and he found it easy too.
My husband uses the computer to surf the web, watch some videos and online series (we had to install non-free flash plugin from Adobe #grr), read mail from the browser, write something in LibreOffice and print it (hey! we just plug the printer/scanner and it works, no need to install drivers!), scan some image and send it by email… I set Debian as default in GRUB, and the switch from Windows has been very natural for him (he was already using Firefox and LibreOffice in Windows. He still says “I’m a Windows user” although he is just using Debian for months!).
He bought an IPhone 4S (#grr!) and I tried to connect it as shown in the corresponding Debian wiki page, but it didn’t work (I got “segmentation fault” when connecting the phone). However, it is recognized by Shotwell and we can copy all the photos and videos to the computer, which is what we wanted to do. So no problem on that side, either.
In conclussion, one more computer at home running Debian (“future stable”), and we don’t run Windows at home anymore :)
Filed under: My experiences and opinion Tagged: Debian, English, Moving into free software
Until now, I usually run Debian stable at work (in my desktop PC) and stable or testing at home in my laptop. I was upgrading to testing during the freeze, and then, stay in testing (future stable) or stable (when it’s published) until the next freeze.
I have changed this ‘conservative’ pattern. I’ve been running Jessie for many months now, and here I’ll document the different experiences in the computers that I use.Upgrade or clean install?
I decided to upgrade my computers instead of making a clean install (except in the ones that were not running Debian).
Although the upgrade process have been fine, I’m still not sure which is the best for my needs. Installing from the beginning forces me to re-read the feature list of the different pieces of software and choose the one that fits best (not the one that I was using some years ago). And maybe I just don’t need that non-free driver anymore because there’s free replacement already, the installer is wise. OTOH, upgrading is easier and quicker, and I got all my software and configurations (and my rubbish) there, nothing is lost.The computers
Here I will link the blog posts of each computer that I upgrade, when I finish writing the corresponding articles:
- Husband’s laptop (Acer 5250): Clean install – Done, and OK!
- My laptop (Compaq Mini 110c): Upgrade – Done and OK!
- Home server (HP Microserver N54L G7): Upgrade – Done and OK!
- PC at work (motherboard Asus P5KPL-AM-SE): Upgrade – Done, some issues.
- Mini-laptop Airis Kira N7000 (ARM board, 128MB RAM) – Clean install – Pending
Filed under: My experiences and opinion Tagged: Debian, English, Moving into free software
In An introduction to Git Part 1, you learned a littl
Welcome UX Design experts. We want to hear your latest thoughts, ideas, techniques and analysis on the latest state of the web. If you’ve got a burning idea you want to share about how to do things better, we want to hear about it.
We’re looking for talks on:
A few months ago I was asked to help manage our company blog. As a busy drupal developer, I had little time to post all of our new blog content on every social media site. So I decided to automate this so I could spend more time on client projects.
My first step was to look around and see what was currently available. Although there was some options, I found them to be a bit heavy for my application.
One of the things I was looking for was to be able to choose what social networks our content would be posted to. For example, I wanted to be able to choose to post this page to...Read More
Yesterday I released version 0.8 of AppStream, the cross-distribution standard for software metadata, that is currently used by GNOME-Software, Muon and Apper in to display rich metadata about applications and other software components.What’s new?
The new release contains some tweaks on AppStreams documentation, and extends the specification with a few more tags and refinements. For example we now recommend sizes for screenshots. The recommended sizes are the ones GNOME-Software already uses today, and it is a good idea to ship those to make software-centers look great, as others SCs are planning to use them as well. Normal sizes as well as sizes for HiDPI displays are defined. This change affects only the distribution-generated data, the upstream metadata is unaffected by this (the distro-specific metadata generator will resize the screenshots anyway).
Another addition to the spec is the introduction of an optional <source_pkgname/> tag, which holds the source package name the packages defined in <pkgname/> tags are built from. This is mainly for internal use by the distributor, e.g. it can decide to use this information to link to internal resources (like bugtrackers, package-watch etc.). It may also be used by software-center applications as additional information to group software components.
Furthermore, we introduced a <bundle/> tag for future use with 3rd-party application installation solutions. The tag notifies a software-installer about the presence of a 3rd-party application bundle, and provides the necessary information on how to install it. In order to do that, the software-center needs to support the respective installation solution. Currently, the Limba project and Xdg-App bundles are supported. For software managers, it is a good idea to implement support for 3rd-party app installers, as soon as the solutions are ready. Currently, the projects are worked on heavily. The new tag is currently already used by Limba, which is the reason why it depends on the latest AppStream release.How do I get it?
All AppStream libraries, libappstream, libappstream-qt and libappstream-glib, are supporting the 0.8 specification in their latest version – so in case you are using one of these, you don’t need to do anything. For Debian, the DEP-11 spec is being updated at time, and the changes will land in the DEP-11 tools soon.Improve your metadata!
This call goes especilly to many KDE projects! Getting good data is partly a task for the distributor, since packaging issues can result in incorrect or broken data, screenshots need to be properly resized etc. However, flawed upstream data can also prevent software from being shown, since software with broken data or missing data will not be incorporated in the distro XML AppStream data file.
Richard Hughes of Fedora has created a nice overview of software failing to be included. You can see the failed-list here – the data can be filtered by desktop environment etc. For KDE projects, a Comment= field is often missing in their .desktop files (or a <summary/> tag needs to be added to their AppStream upstream XML file). Keep in mind that you are not only helping Fedora by fixing these issues, but also all other distributions cosuming the metadata you ship upstream.
For Debian, we will have a similar overview soon, since it is also a very helpful tool to find packaging issues.
As a front-end developer working with Drupal, I often need to create custom Ctools layout plugins. Ctools is an essential suite of tools for Drupal developers and the basis of many popular modules, including Views, Panels, Context and Display Suite. Its layout plugins provide a flexible alternative to Drupal’s core page region system.
Creating a custom Ctools layout plugin for Drupal is actually quite easy. You define your layout in a .info file, create the html structure in a template (*.tpl.php), style it in a stylesheet (*.css or *.scss) and provide a thumbnail image so the site administrator has an idea of what it looks like. Each of these files follows similar but slightly different naming conventions. This can be tedious when you need to create a number of custom layouts for a project as we often do at Aten.
My previous workflow looked like this.
- Find another layout plugin – either an existing custom layout or one from the Panels module.
- Copy that folder into the plugins folder in my module or theme.
- Rename the folder to match my plugin.
- Rename all the files to match my plugin’s name, using the appropriate naming convention and file extensions.
- Edit the .info file to point to the appropriate files and change the array of regions to match the new layout.
- Edit the template file to match the newly created regions.
- Write the CSS to style the layout.
- Create a new thumbnail image.
A lot of these steps consist of copy, paste, find and replace – the kind of stuff that’s better suited for computers. That's where Yeoman comes in. Yeoman is a scaffolding tool. It's most often used to quickly create boilerplate code that can be customized to your needs.
I recently published a Yeoman generator that automatically creates a ctools layout plugin based on a few simple settings. Now my workflow looks like this:
- Create a directory for my plugin.
- Type yo ctools-layout.
- Answer questions about my layout.
- Add any extra markup to the template file.
- Write the CSS to style the layout.
- Create a new thumbnail image.
The new workflow eliminates the tedious tasks and allows me to focus on the code that makes a given layout unique: markup, style and a thumbnail.
Here’s how to use it.
To install Yeoman type the following into your terminal:npm install yo -g
The -g flag installs this package globally. Doing so allows you to run the yo command outside of an existing node project. A common Yeoman use case is scaffolding out a brand new project, after all.
Note: Depending on your environment, you may need to run these commands with sudo.
Now you have the general Yeoman application. But to be useful, you need some generators.npm install ctools-layout-generator -g
The ctools layout generator assumes you already have a custom module or theme that you are adding a layout to. For this example we'll assume this custom layout is in our theme. From your theme's root directory create a new directory for your layout plugin, change to your new directory and run the ctools_layout generator command.mkdir plugins/layout/landing_page cd plugins/layout/landing_page yo ctools_layout
Yeoman will prompt you with a few questions about your layout, such as the name of your layout, the name of the module or theme it exists in and the regions you want to include. After answering the questions, Yeoman creates all the necessary files needed for a working layout.
The ctools layout generator makes no assumptions about what your layout looks like or the actual CSS styles and markup needed to make it functional. That's your world! It's completely up to you. It simply takes your list of regions and adds them to the layout's .inc file and to the template file in which you can add the appropriate markup.
Similarly, the generator will add a placeholder .png thumbnail of your layout. The generator has no idea what you have in mind for your layout, so you'll want to create your own thumbnail and save it over the placeholder. The thumbnail is important as it gives the end user a good idea of what the layout looks like. I've shared a Photoshop template that I use for creating layout thumbnails.
I hope you find this useful. If run into any problems or have feedback, please create an issue on github.
P.S. In case yeoman isn’t your thing, there is a drush plugin that has similar functionality and works for more than just layouts.
I just updated all prior 16 posts in this series with up to date screenshots and text over the weekend and here is the new post!
In the introduction to content and configuration translation piece we discussed what is considered content in Drupal 8. This is a somewhat misleading term because custom blocks, custom menu items and even user entities (user profiles) are considered content in terms of their implementation.
Content is always stored as entities. The main difference between configuration and content entities is configuration is usually created on the backend (think views, vocabularies, etc.) while content is usually created on the frontend (think free tagging taxonomy terms, comments, blog posts). This is not a black and white differentiation but it helps think of the categories. The other key differentiator is content entities usually get to have configurable fields. You can add new fields to user profiles, taxonomy terms or comments. Again there are exceptions, for example custom menu items cannot get configurable fields in core. Finally, there are even content entities that will not be stored, in Drupal 8 contact form submissions are content entities that live only until they are sent via email. For this tidbit we are concerned for content entities that are stored and multilingual.
I originally thought taking part in FOSSOPW is a great chance to lift my coding skills and I shouldn’t miss it. As time passes by, I now have a new thought towards it.# 1 It do improves your coding skill.
Zack, Matthieu and I often have discussions on coding style. For example, once Zack said, “For code like this, you should explicitly use an if/else clause, not if-return.” I was totally unaware of this sort of issue. Actually I even didn’t know how I should call this problem. Matthieu gave me a detailed FYI link on this in no time.
Besides, my completeness of thinking is also trained. Recently, I was fixing a “HTTP GET Method ?suite=suite-name” issue. It’s a trivial task. And you know most trivial tasks require lots of scattered modification on the source code base. I did have fixed most places, such as the pages of “/src/packagename” and “/search/”. Zack did a thorough review, and pointed out that the pages rendered by “/prefix” has some malformed urls in the HTML. Waiiiit, I should have noticed it. But somehow I missed it. Maybe because my mind was wandering at that time? This made me think, I shall have a thorough view of what I should do before getting my hands dirty. Or more preferably, if I could write down what I exactly want to achieve before coding, then silly problems definitely wouldn’t occur. This may sound a little bit like TDD. ;).# 2 It makes you look like a (not-that-good) ninja.
I use a macbook. It’s not my fault! I’ve tried several times, but I never successfully find a laptop that is not capable of boiling eggs when running Debian. (and especially KDE+Debian). So I have no way but switched to OSX. The development of Debsources happens on a remote Ubuntu LTS (now Debian SID, haha) virtual machine. Of course I have to install all the dependency on my own, e.g., Postgres, set up port-forwarding, e.g., ssh -D, write automate shell scripts, e.g., dash, but more importantly, I am forced to live under the dark terminal with no GUI. You know the feeling when pain hurts? Yes, exactly! But I survived. How shall I call myself now? A dedicated with-a-lot-of-useless-plugin-installed vimmer? A fond-of-fancy-window tmux-er? Yep, both. I finally found a comfort zone under the black-white-blinking screen. I wonder how people feel when they see a girl hanging out in the library, facing a full-screened black console, typing at a speed of 140wpm (Yeah, I am kidding). I don’t know, but please don’t call me a geek. Show me your respect, I am a ninja!# 3 It tells you communication is the most important.
I bet anyone who has participated in a group-based project would understand what I mean. For one perspective, communication helps to eliminate misunderstanding. So I won’t doing some useless stuff for all day and finally find out that it totally doesn’t meet the requirement. On the other hand, it speeds up your learning process. I often have problems on git. So in the email I will complain if I mess up with the git repo. After a short while, my dear mentors will reply in detail on how to correctly do the git stuff.My OPW journey is cool! ;).
Having just completed presenting the Drupal career training portion of AcquiaU, we are anticipating great experiences for all ten students as they begin their eight weeks of rotations within three different business groups within Acquia. The past two months have been a whirlwind of teaching, learning and team building, which provided great insight into a forward-thinking approach to building Drupal talent, made possible by the commitment of Acquia.
We are pleased to have contributed to the new AcquiaU with the customization of our Drupal Career Online curriculum. I’d like to share some great lessons learned, as well as introduce the ten people who were lucky enough (luck favors the prepared) to be selected for this amazing program.-->
About a year and a half after I started writing the openstack-debian-images package, I’m very happy to announce to everyone that, thanks to Steve McIntyre’s help, the official OpenStack Debian image is now generated at the same time as the official Debian CD ISO images. If you are a cloud user, if you use OpenStack on a private cloud, or if you are a public cloud operator, then you may want to download the weekly build of the OpenStack image from here:
Note that for the moment, there’s only the amd64 arch available, but I don’t think this is a problem: so far, I haven’t found any public cloud provider offering anything else than Intel 64 bits arch. Maybe this will change over the course of this year, and we will need arm64, but this can be added later on.
Now, for later plans: I still have 2 bugs to fix on the openstack-debian-images package (the default 1GB size is now just a bit too small for Jessie, and the script exits with zero in case of error), but nothing that prevents its use right now. I don’t think it will be a problem for the release team to accept these small changes before Jessie is out.
When generating the image, Steve also wants to generate a sources.tar.gz containing all the source packages that we include on the image. He already has the script (which is used as a hook script when running the build-openstack-debian-image script), and I am planning to add it as a documentation in /usr/share/doc/openstack-debian-images.
Last, probably it would be a good idea to install grub-xen, just as Ian Campbell suggested to make it possible for this image to run in AWS or other Xen based clouds. I would need to be able to test this though. If you can contribute with this kind of test, please get in touch.
Feel free to play with all of this, and customize your Jessie images if you need to. The script is (on purpose) very small (around 400 lines of shell script) and easy to understand (no function, it’s mostly linear from top to bottom of the file), so it is also very easy to hack, plus it has a convenient hook script facility where you can do all sorts of things (copying files, apt-get install stuff, running things in the chroot, etc.).
Again, thanks so much to Steve for working on using the script during the CD builds. This feels me with joy that Debian finally has official images for OpenStack.
We worked hard during a few days and developed our own module called Private message with node.js.Read more
I go to the gym every couple of days. I lift things up, then put them down, and sometimes I repeat this process another 30 times. When I'm done I write down what I've done, how many times I did the lifty-droppy thing, and so on.
I want to see pretty graphs. I want to have records of different things. I guess I just need some simple text-boxes:deadlift 3 x 7 @ 210lbs.
etc. Sometimes I use machines so I'd say instead:converging seated-row 3 x 8 @ 150lbs
Anyway that's it. I want a simple GUI, a bit like a spreadsheet where I can easily add rows of each session. (A session might have 10-15 exercises in it, so not many.) I imagine some kind of SQLite database for the back-end. Or CSV. Either works.
Writing GUI software is hard. I guess I should look at GtK or Qt over the next few days and see if it is going to be easier to do it online via a jQuery + CGI system instead. To be honest I expect doing it "online" is liable to be more popular, but I think a desktop toy-application is just as useful.
I'm planning to take this concept further and I just whipped up another Python script, exposing Nagios issues as an iCalendar feed.
One interesting feature is that you can append a contact name to the URL and just get the issues for that contact, e.g.:http://nagios-server.example.org:5001?contact=daniel Screenshots
- Content editors want to embed rich media, callouts, and references to related content anywhere within their WYSIWYG. They love the Body field and want more buttons added to the WYSIWYG.
- Web developers want to add additional fields for media, attachments, related content to support rich content relationships and access control. Web developers hate the Body field and wish they didn’t need a WYSIWYG.
In the latest 2.30 version of Open Atrium, we attempt to help both content editors and web developers with a new approach to building rich story content using the Paragraphs module. Rather than having a single WYSIWYG body, content editors can build their story using multiple paragraphs of different types and layouts. The order of these paragraphs can be rearranged via drag and drop to create long-form content.
Site builders can add their own custom paragraph types to their sites, but Open Atrium comes with four powerful paragraph types “out of the box”:(1) Text Paragraphs
The simplest paragraph type is the “Text” paragraph. It works just like the normal Body field with it’s own WYSIWYG editor. But an additional Layout field is added to control how the text is rendered. There are options for multiple columns of wrapping text within the paragraph (something nearly impossible to do with the normal Body field), as well as options for left or right floating “callouts” of text.(2) Media Gallery
The “Media Gallery” paragraph handles all of the images and videos you want to add to your story. It can replace the normal Attachments field previously used to add media to a document. Each Media paragraph can contain one or more images, videos, or files. The Layout field controls how that media is displayed, providing options for left or right floating regions, or a grid-like gallery of media. Videos can be embedded as preview images or full video players.
When floating media to the left or right, the text from other paragraphs will flow around it, just as if the media had been embedded into the WYSIWYG. To move the images to a different part of the story, just drag the media paragraph to a new position in the story.
In Open Atrium, images directly embedded into the Body WYSIWYG field becomes Public, bypassing the normal OA access control rules. However, anything added to a Media paragraph works more like the Attachment field and properly inherits the access permission of the story document being created. Thus, the Media paragraph provides a way to embed Media within your story while retraining proper privacy permissions.(3) Snippets
The “Snippet” paragraph type allows you to embed text from any other content on your site. You can specify whether the Summary, Body, or full Node is embedded and also control the Layout the same as with Text paragraphs. You can also either display the Title of the referenced content or hide the title, or override the title with your own text.
One of the best features of Snippets is the ability to lock which revision you want to display. For example, imagine you want to embed a standard operating procedure (SOP) within your story document. You create a Snippet paragraph that points to the SOP. However, if the related SOP node is updated in the future, you don’t want your old document to change. For compliance purposes it still needs to contain the original SOP text. By “locking” the snippet to the old revision, the old document will continue to display the original SOP even if the SOP is updated later. If you “unlock” the snippet, then it will display the latest version of the related SOP.
Open Atrium access controls are also respected when displaying snippets. If you reference content that the user doesn’t have permission to view, that snippet will be removed from the displayed text. Users still only see the content they are allowed. This provides a very powerful way to create rich documents that contain different snippets of reusable content for different user roles and permissions. Similar to adding additional fields with Field Permissions, but much more flexible and easy to use.(4) Related Content
The “Related Content” paragraph type is similar to Snippets, but displays the Summary or Full rendered node of the related content. Like the Media paragraph, the Related Content can contain one or more references to other content on the site. The Layout provides options for displaying the content as a table of files, or a list of node summaries (teasers), or as full node content. When full node content is used, any paragraphs used in the related content will also being displayed (paragraph “inception”!). In addition, any special fields from the full related node can be shown. For example, a Related Event will show the map of the event location. A Related Discussion will show all of the discussion replies and even provide the Reply Form, allowing you to reply to a related discussion directly from the story document itself!
Related Content is also a bi-directional link. When you view the related content node, a sidebar widget called “Referenced From” will show all of the stories that reference the node being viewed.A Real World Example
To pull all of this together with a real-world example, imagine that you are scheduling a Meeting. You want to create an Agenda for that meeting and allow your team to discuss and edit the agenda before the meeting. In Open Atrium you can now do this all from a single document:
- Create the Event for the Meeting, adding your team to the Notifications
- Add a Related Content paragraph for the meeting Agenda document
- Add a Related Content paragraph for the agenda Discussion
Open Atrium is smart about where this related content is created. If you already have a section for documents, the Agenda will be created within that section. If you already have a section for discussions, the related discussion will be placed there. You can change these locations if you wish, but the default behavior reflects the most common information architecture.
When your team members receive the email notification about the meeting and click the link, they will be taken to your Event and will see the agenda document and discussion as if they were a normal part of the event body. They can view the agenda content directly and can post replies directly into the discussion reply field. They don’t need to go to separate places on the site to see the document or discussion. If you *do* view the document or discussion nodes directly, such as from a search results page, you’ll see a link back to the meeting event in the References From list in the sidebar.Conclusion
Not only do the Paragraph features help content editors build rich stories quickly and easily, they allow web developers to create related documents, linked content, better search results, better data structures. It’s still not a magical unicorn wysiwig of content editor’s dreams, but it’s a significant step for Open Atrium and Drupal. It opens a whole new world of collaboration where all related content can be viewed together.
Looking for more information about Open Atrium? Sign up to receive Open Atrium newsletters and updates! Don’t miss our winter release webinar on Wednesday, January 28th, at 11am EST!
- the nouveau graphics driver was not handling the graphics card very well (hangs when using the DRM after putting the computer to sleep once, garbage screen on various apps, slow 3D rendering), and I could never get the proprietary nvidia drivers to work (would give blank screen at boot time)
- very unstable wireless (at least with my box home, but not with all the ones I've tried)
- and the most painful was the need to recompile the kernel by hand, with the following modifications from stock debian kernel:
-CONFIG_X86_SYSFB=y +# CONFIG_X86_SYSFB is not set -CONFIG_FB_SIMPLE=y +# CONFIG_FB_SIMPLE is not set Without these modifications, the screen would be garbled some 5-6 seconds after boot (but SSH would still work, as far as I remember).