Feed aggregator

Introducing Google for Work (the artist formerly known as Enterprise)

Google Enterprise Blog -

Posted by Eric Schmidt, Executive Chairman

Work is where you spend a lot of your time. So we’ve always believed that it should be meaningful—not a daily grind, done in isolation on an old desktop in a sea of cubicles. Even more, we believe that technology should make work better. It should make it easy not just to get things done, but to get things done with people who inspire you, at the times and in the places where you work best, and in a way that lets you make an impact, no matter what your job is, or what industry you’re in.

Ten years ago, we started bringing Google’s consumer technology—along with the features, controls and services businesses need—to work. We first brought search and then Gmail to businesses. Today we also offer the scale and reliability of Google’s infrastructure to developers with Google Maps and Google Cloud Platform, and have extended into hardware with Android and Chromebooks. Along the way we’ve invested in what matters to our customers and partners—security, transparency, compliance and customer support. And our team, the breadth of our offerings, and our commitment to business customers have all increased substantially.
Work today is very different from 10 years ago. Cloud computing, once a new idea, is abundantly available, and collaboration is possible across offices, cities, countries and continents. Ideas can go from prototype to development to launch in a matter of days. Working from a computer, tablet or phone is no longer just a trend—it’s a reality. And millions of companies, large and small, have turned to Google’s products to help them launch, build and transform their businesses, and help their employees work the way they live. In other words, work is already better than it used to be.

But technology for the workplace isn't just about a better way of doing business. It's about empowering anyone, whether they're a developer with an idea in their basement or a baker with a better cupcake or a company with thousands of employees, to have an impact. We never set out to create a traditional “enterprise” business—we wanted to create a new way of doing work. So the time has come for our name to catch up with our ambition. As of today, what was called Google Enterprise is now, simply, Google for Work. When we use the tools that make our lives easier—Google Apps, Maps, Search, Chrome, Android, Cloud Platform and more—work gets better. And that’s what we’re working on—the best of Google, now for work.

Drupal Watchdog: Composer: Sharing Wider

Planet Drupal -

Feature


Drupal has long had a strong collaborative culture. We share modules, we share development tasks on core and modules, and we share infrastructure on Drupal.org. That's a critical part of the health of our community: Sharing is how Open Source works.

The broader PHP world, however, has long sucked at sharing. Every project is its own island; sharing code between projects has been difficult, and managing third party libraries a pain. Just about the only option was PEAR, but unless you had root access on every server you needed, and were running only a single application per server, it wasn't really useful.

That was then, this is now. Enter Composer, a PHP dependency management tool that works. Composer began life in late 2011 in the Symfony community but was deliberately built to be project-agnostic, and today is being used by thousands of projects large and small, including Drupal.

Composer Basics

Composer consists of two parts. One is Packagist.org, which is a central clearinghouse of Composer-compatible packages. As of July 2013, Packagist offers over 13,000 packages, ranging from simple libraries to complete frameworks. The other part is Composer itself, a command line PHP application that is dead simple to install. By default, Composer will download packages from Packagist.org but you can also set up your own package server, or even just one-off Git repositories, to host Composer-capable code. All you need to make it work is a simple JSON file.

Let's start off with a trivial example. We’ll write a super-simple script that uses the Guzzle HTTP client (now bundled with Drupal 8). To start off, create your project folder. Inside it, create a directory called src. That's where we'll put all of our code. Now create a file called composer.json with the following contents:

Drupal core announcements: No Drupal 6 or Drupal 7 core release on Wednesday, September 3

Planet Drupal -

The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, there have been three releases (security releases as well as bug fix releases) in the last month and a half, and not as many changes have been committed to the development version since then as would normally warrant yet another new release.

A Drupal 7 bug fix release during the October release window is likely instead.

Upcoming release windows include:

  • Wednesday, September 17 (security release window)
  • Wednesday, October 1 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Coming soon: NTEN’s Nonprofit Tech Job Board

NTEN -

“Where can I post a job?”

That’s one of the most common questions we get at NTEN, and we’ve repeatedly heard from many of you in the NTEN community that you’d like to see a job board on NTEN.org. Well, we take your requests seriously; and we are excited to announce that a job board is underway!

In just a few weeks, we’ll be unveiling NTEN’s Nonprofit Tech Job Board, a platform dedicated exclusively to paid nonprofit technology career opportunities. The job board will live on nten.org, and be accessible from the navigation menu on any NTEN webpage for anyone to access, search job listings, and post positions. Job postings to the job board will cost $50 for NTEN Members and $100 for Non-Members, for a 30-day listing.

The job board will present a change as we’ve currently pointed people to our NTEN Discuss group to post job opportunities. With the new job board, any job postings made to the Discuss group or other myNTEN groups will be deleted. This way we are keeping the focus of the online groups on the conversations, information sharing, and connections between community members. 

The charge for posting a job is also a significant change, but we believe the added value of the formal job board more than makes up for this cost. With a dedicated job board, your postings will be in a prominent place on the Web and the NTEN website. The job board will be featured in NTEN’s monthly Member Newsletter that goes to over 8,000 individuals, and in our monthly Connect Newsletter with over 33,000 subscribers. Job postings will also receive social media promotion. We’ve been very conscious to keep the price affordable and below the cost of most job posting sites. As an NTEN Member, you’ll receive 50% off any job postings - which represents a substantial savings, especially with multiple job postings.

We can’t wait to unveil the new job site later this month! Have any questions or concerns about the upcoming job board? Post them here and we’ll be sure to address them.

FAQs about NTEN's Nonprofit Tech Job Board

Here’s the scoop on the upcoming job board, and the answers to your questions about this new NTEN feature:

  • Why is NTEN offering a job board to begin with? Job postings on the NTEN Discuss list or Community of Practice groups have increased in the last couple of years and we've heard about it: many participants flag these posts as off topic or even spam, sending them to staff with requests to help moderate and keep discussions on topic. We don't want to discourage hiring from this community! Instead, we've taken the feedback from community members, our committees, and board and are launching the job board later this month in beta. We will continue to gather feedback, request your recommendations, and further refine the job board to serve this community. 
  • Hold on a minute! Why should we have to pay to post a job when we used to post jobs for free in the NTEN Discuss group? The job board will serve as a dedicated space for these listings, and it will be promoted throughout NTEN's emails and community platforms. Plus, all posts will get some social media love, too. 
  • Where will the job board be? The job board will live right on the nten.org site. You’ll be able to access the job board from the navigation menu on any NTEN webpage. 
  • How much does it cost to post a job? Job postings are $50 for NTEN Members and $100 for Non-Members.
  • How long will my job posting be live? Jobs will be listed for 30 days, but you may choose to re-post a job after 30 days.
  • Can I post a volunteer job? Job postings are only for paid positions. Your posting does not have to be for a full time position.
  • How do I make sure we find the best candidates possible? There are many other platforms for posting nonprofit jobs. We recognize that the NTEN community is special: filled with people dedicated to using technology to more effecitvely and efficiently meet their missions. We think people in this community are great candidates for your next job opening and are excited to offer a way for you to share job postings. We also encourage you to post jobs, volunteer roles, or board member opportunities on Idealist.org and with your state nonprofit association. 
  • When can I post? We will release the Nonprofit Tech Job Board later this month - stand by for announcements via email, blog, and social media!

Microserve: Omega 4.x: setup and comparison

Planet Drupal -

About a year ago I wrote a post on my personal blog about theming with Zen versus theming with Omega, and someone pointed out that there was a new release of Omega. However, until now, I've not been able to look and see how it differs. Armed with a free week to do some personal learning and keen to finally try installing and playing with Sass for the first time, Omega 4 became my guinea pig.

This post serves two purposes: it's partly a comparison between Omega 3 and Omega 4, but it also documents how to create an Omega 4 subtheme and set up Sass for the first time.

Before we begin About Omega 4.x

Omega is one of the best-known themes for Drupal, with over 80,000 installations at time of writing. Version 4.x takes a huge step away from 3.x. It's not just different: it feels like a whole new piece of software. The project page says:

Omega 4.x is a base theme framework aimed at themers who want to gain full control over the theme through code, rather than a user interface. If you depend on the user interface you can continue using Omega 3.x.

Nearly everything has been rewritten - the CSS has been optimized and cleaned up, partly to conform to new Drupal 8 standards, making it more future-proof; there are premade layouts available; and some functionality has been split out into extensions, while other bits have been combined into the main theme.

There are also some new features, including a browser width indicator (useful if you're doing responsive development in the browser). My favourite thing is the Drush integration: for 3.x you had to install Omega Tools to get Drush commands, but it's now all built in.

Differences

While I didn’t like the UI for rearranging components, that's probably one of the features I miss the most. In fact, there are a lot of differences in the theme settings: namely, in Omega 3, you could overlay the grid columns, but all you get in Omega 4 is a region demonstration. Everything else is now handled in code.

I can get this sort of thing from the block page... why do I need it permanently?

That does (in theory) make it easier to create new layouts. One of my biggest criticisms of Omega 3 was that it was so difficult to change the grid, but now you can create multiple layouts . I can see that being useful for a multi-site installation, and, if you pair it with Context , it could be useful for page-by-page layouts. You can also use the ones provided with Omega or its default subtheme Ohm - I've become quite a fan of Hero (above).

There's no more configuration through Delta (although I'm assured that's still possible, despite the project page explicitly stating that "Omega 4.x should NOT be used with Omega Tools and Delta"), but pleasingly, there's no more enormous and unwieldy .info file with two dozen files attached. Everything has been shifted into the backend, and the CSS is all compiled with Sass/Compass now.

It is worth pointing out that the huge, unwieldy .info file will return if you choose to stop serving the theme settings from a variable. This will export the settings and put them into the .info file, improving the performance.

For those who have delved into Sass before, you should find it easy enough to start using Omega 4 straight away. I’ve never used Sass before, so this will be a learning curve for me.

If you're looking for a starting point, you can try looking at the official Omega theme documentation, but I warn you that it's not the best place to go for information about installing Ruby and other component features.

Installation

Before I begin I just want to link to this awesome tutorial on creating new Omega subthemes by Daniel Sipos, which cleared up lots of things for me. Without that I'd probably still be trying to install Sass several days later.

So if you're looking for a real tutorial, go there. I'll just skim through basics. I'm not going to hold hands, but I will provide links where possible.

Omega itself

First and foremost, you'll need to download and install Omega. Whether you do it through Drush or by visiting the project page and downloading a zip file is up to you.

Make sure you use the latest development version (20th August) rather than the stable release: it fixes a bug that meant the right extensions weren’t being found.

Why are we installing Omega first? Easy: when you make your subtheme in Drush, it'll tell you what version of Ruby you need to install for Sass to work.

Ruby

In order to use Sass , make sure you have Ruby installed. If you're on a Mac, it should already be there, although you might want to try installing RVM (Ruby Version Manager) .

It's worth pointing out that if you're on a production server it's best practice not to install Sass unless you absolutely have to. Use Sass in your dev environment, fine, but only upload your compiled CSS files to your server.

Alternatively, if you don't want to use Sass at all, don't bother installing Ruby and ignore the contents of the Sass directories.

Omega subtheme

Once RVM is set up, create a subtheme. If you're feeling brave you can do it manually , but if you've got Drush installed it's so much easier just to run through the wizard with this command:

$ drush omega-wizard

Run that inside the site directory, follow the instructions, and enable it if you want. See? Much easier than copying and renaming files. And all on a new Drupal installation, too: I really appreciated that I didn't have to install anything to create a subtheme.

Gems and finishing

Finally, navigate (in your command line) to the base folder for your theme. You should get a notice:

ruby-1.9.3-p547 is not installed. To install do: 'rvm install ruby-1.9.3-p547'

If you do, then go ahead and install it. The Ruby version is related to the exact version of Omega you've installed, so pay close attention to the version number and run the command as it’s written.

In the base directory for the theme, you'll see there's a file called "Gemfile". This dictates which gems should be installed for the theme to work. Just run this command:

$ bundle install

That should fetch and download everything you need, and that's pretty much it!

The blog post I mentioned has more information about installation and some troubleshooting, so refer to that if you're stuck.

Now you can start editing the files in the themename/sass folder. Run this in your command line:

$ compass watch

for live updates (it will "watch" the SCSS files and automatically compile them when you save a change).

Creating layouts

Creating a new subtheme is much easier in Omega 4 than in 3 (or even Zen), with a caveat of "if you have Ruby and Sass already installed". If you've got to here and are thinking "yikes, that's a whole lot of work" or "that's too much command line work", you might think about trying Zen or Sasson instead.

But if you've got this far, chances are you want to create a layout that's not a 1-2-1 grid layout. There are a couple of ways to go: you can copy one supplied by Omega/Ohm (such as Hero) and modify it, or you can create your own.

Layout options for Omega 4 - default plus "Hero" from Ohm

I quite like Hero, so I stuck to using that. You can see some of the basic layout options on the Appearance page. This is as close to Omega 3's user interface as you'll get.

Luckily, there are some articles on Drupal.org about creating a new layout for Omega. This first one explains the basics - what you'll need in order for the layout to work - while a second one goes into a little more detail about folder and file structure.

This is much more complicated than Omega 3, but at least you can change the layout and grid if you want to. You could take some inspiration from around the web to create something new - including Gridset - and it seems to be quite similar to creating a new subtheme. They come complete with a pseudo-info file and everything!

It can be easier to make those grids if you use Susy and Breakpoint , two Sass extensions that'll do the grunt work for you. Then it’s on to the styling!

Sass

It took me a while to get my head around "how Sass works". I understood the variables and mixins - that was what I was most keen to try - but I found it hard to understand partials and compiling the files.

Actually, it was all a lot easier than I expected. You write your SCSS files then add them all to one main file with several @includes in it. Lots of people have written about their chosen directory structures; Omega gives you some folders as a starting point. Check out Stu Robson's "Structuring my Sass 101" post too.

One thing to bear in mind is that many people offering advice about file structures are not using Drupal (or an Omega subtheme)! You might find their advice isn't always relevant.

Finally, it's important to consider how you can integrate your Sass files and your version control. Some suggest only committing the uncompiled files for several reasons, such as forcing other developers to use the “correct”, while others say it doesn't make much difference. Right now I'm primarily a back-end developer, so I'm not sure what the best workflow is, but I’ll be interested to find out what does and doesn’t work.

Wrapping it up So who is Omega 4.x for?

You should consider using Omega 4.x if ...

  • ...you're comfortable with getting your hands dirty and don't mind coding a layout from scratch.
  • ...you like using, have used, or want to start using Sass to write your CSS.
  • ...you want to create a whole new layout from scratch, with a custom grid system.
  • ...you don't need a user interface to modify the theme settings.
  • ...you're making a push towards more modular, SMACSS -based CSS.

Otherwise, you might want to consider using Omega 3.x, or a different theme altogether.

Other useful links

Drupal core announcements: This month in Drupal Documentation

Planet Drupal -

This is the 'almost' monthly update from the Documentation Working Group (DocWG) on what has been going on in Drupal Documentation. Because this is posted in the Core group, comments for this post are disabled, but if you have comments or suggestions, please see the DocWG home page for how to contact us. Enjoy!

Notable Documentation Updates Thanks for contributing!

Since our last post from August 1, 223 contributors have made 657 Drupal.org documentation page revisions, including 4 people that made 20 or more edits (thank you erok415, Jay.Chen, iantresman & drumm) and one person that did a whopping 66 revisions (keep rocking kaare!).

Report from the Working Group
  • We are preparing a Documentation sprint at DrupalCon Amsterdam where we hope to finalize the work on the Drupal 8 help texts (to help out, see https://www.drupal.org/node/1908570). We will also make a start with creating or updating docs for the D8 core modules. We'll be using documentation issue tag "docsprint" to tag issues that we think will be good for sprints, over the next two months especially.
  • After an initial period of setting up the DocWG, we have now opened up the monthly meeting of the Documentation Working Group to anyone who would like to attend. Let me know if you want to join the meeting.
Documentation Priorities

The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.

If you're new to contributing to documentation, these projects may seem a bit overwhelming -- so why not try out a New contributor task to get started?

KnackForge: Adding a clear button to Drupal form API text field

Planet Drupal -

We wanted to have a quick clear button for any text field (similar to address bar of browsers in mobile and tablet devices). Snapshot below might explain it much better. In this you are seeing email search field in newsletter filter form.

While I was in search for creating this, I found HTML5 is as the way to go. One can simply create that by using "search" input type. The proper HTML tag for the same is below,

Web Omelette: PHP: Using the usort / uasort functions

Planet Drupal -

Have you ever had to sort an array in PHP? There are a bunch of functions available, the most common being sort(). This function does a default sorting of the values in your array. So if you have numbers or want to do alphabetical sorting, sort() will get the job done.

But what if you require a more complex sorting logic? Let's say you have an array of names that need to be sorted in a specific order. I don't know, because your client says so. Let me show you how.

Let's say your DB returns a list of names in an array:

$names = array("Christian", "Daniel", "Adrian");

And your client says they need to be arranged in the following order: Adrian, Christian, Daniel. You can use the usort() function together with a comparator function you write yourself. How does this system work?

As a second argument of the usort() function, we pass in the name of our custom comparator function. The way this gets processed is that all the values in the array that needs sorting are passed to this function 2 at the time (usually you'll see them as $a and $b). This is done to determine which one takes precedence over which. The comparator has to return 0 if the 2 values are considered equal, a negative integer if the first value is less than the second value or a positive integer if the second value is less than the first. What less means is up to you to determine. So let's put this in practice with our example:

function _name_comparer($a, $b) { $correct_order = array("Adrian", "Christian", "Daniel"); $a_key = array_search($a, $correct_order); $b_key = array_search($b, $correct_order); if ($a_key == $b_key) { return 0; } return ($a_key < $b_key) ? -1 : 1; } usort($names, "_name_comparer");

So what happens in my comparator function? First, I create an array that contains the proper order of the names. This means that each value has an integer key that can be easily compared (and that I store in the $a_key and $b_key variables). After comparing these, I return 0, a negative or positive integer. The result is that the $names array gets resorted in the order they appear in the $correct_order local variable I created. And that's it.

If the $names variable is associative and you need to maintain the keys as they were, you can use the uasort() function:

$names = array( "christian" => "Christian", "daniel" => "Daniel", "adrian" => "Adrian", ); usort($names, "_name_comparer");

The comparator function can stay the same, but the uasort() function will take into account and maintain the index association of your values.

And that's it. Hope this helps.

var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});

Joachim's blog: Graphing relationships between entity types

Planet Drupal -

Another thing that was developed as a result of my big Commerce project (see my previous blog post for the run-down of the various modules this contributed back to Drupal) was a bit of code for generating a graph that represents the relationships between entity types.

For a site with a lot of entityreference fields it's a good idea to draw diagrams before you get started, to figure out how everything ties together. But it's also nice to have a diagram that's based on what you've built, so you can compare it, and refer back to it (not to mention that it's a lot easier to read than my handwriting).

The code for this never got released; I tried various graph engines that work with Graph API, but none of them produced quite what I was hoping for. It just sat in my local copy of Field Tools for the last couple of years (I didn't even make a git branch for it, that shows how rough it was!). Then yesterday I came across the Sigma.js graph library, and that inspired me to dig out the code and finish it off.

To give the complete picture, I've added support for the relationships that are formed between entity types by their schema fields: things like the uid property on a node. These are easily picked out of hook_schema()'s foreign keys array.

In the end, I found Sigma.js wasn't the right fit: it looks very pretty, but it expects you to dictate the position of the nodes in the canvass, which for a generated graph doesn't really work. There is a plugin for it that allows the graph to be force-directed, but that was starting to be too fiddly. Instead though, I found Springy, that while maybe not quite as versatile, automatically lays out the graph nodes out of the box. It didn't take too long to write a library module for using Springy with Graph API.

Here's the result:

Because this uses Graph API, it'll work with any graph engine, not just Springy. So I'll be interested to see what people who are more familiar with graphing can make it do. To get something that looks like the above for your site, it's simple: install the 7.x-1.x-dev release of Field Tools, install Graph API, install the Springy module, and follow the instructions in the README of that last module for installing the Springy Javascript library.

The next stage of development for this tool is figuring out a nice way of showing entity bundles. After all, entityreference fields are on specific bundles, and may point to only certain bundles. However, they sometimes point to all bundles of an entity type. And meanwhile, schema properties are always on all bundles and point to all bundles. How do we represent that without the graph turning into a total mess? I'm pondering adding a form that lets you pick which entity types should be shown as separate bundles, but it's starting to get complicated. If you have any thoughts on this, or other ways to improve this feature, please share them with me in the Field Tools issue queue!

Best Times to Post on Social Media

frogloop -

If you are like most organizations, your staff wears many hats. If you are juggling several tasks including managing social media accounts, check out this data about the best times to post updates. However, before you dive into it, it's important that you remember to look at your own engagement and what the best times are to post for your own organization. Sometimes posting during the "dead zone periods" can be beneficial because you are not competing with all the noise. The best thing that you can do is to test it. 

 

Best Times to Post on Social Media:

Twitter  8pm-8am ET with the worst days being Saturday and Sunday
Facebook  12am-8am ET with the worst days being Saturday and Sunday as well
LinkedIn 9am-5pm ET with Monday and Friday being the worst days
Tumblr   12am-12pm ET
Instagram  12am-8am ET
Pinterest  1am-7am and 5pm-7pm ET
Google+  6pm-8am ET

 

What are the best times you have found to post on social media?

 

MariqueCalcus: Drupal 8 in action

Planet Drupal -

Drupal 8, Plugins, Guzzle, CMI, Caching... If those buzzwords trigger your interest, you should keep reading this article. We will cover those topics as we are building one of our first Drupal 8 modules. Recently one of our clients requested a solution to integrate a custom feed called IBP Catalog. The IBP Catalog is a filterable XML feed, which enable to easily collect web component like banners, documents or even audio files. Those components are selected by the broker through a dedicated website.

Read More...

Pages

Subscribe to Cruiskeen Consulting LLC aggregator