The document provides instructions for installing the Drush command line shell and scripting interface for Drupal. It begins by having users change directories to where they want Drush to be installed, then use wget to download the Drush tarball file from the Drupal.org website. Further instructions will unpack and configure Drush on the system.
Packaging is the Worst Way to Distribute Software, Except for Everything Elsemckern
As part of the 2014 USENIX Release Engineering Summit West, I presented a talk about packaging software and what's wrong with current trends.
Here's the abstract:
Reliably distributing software is a notoriously difficult problem, and almost every operating system and programming language vendor has tried to solve it. This has led to a herd of packaging systems, almost none of which are cross-compatible; some manage system-level software, while others focus on extending their own language (often by trampling on system-level software). And like all competing standards, every packaging system comes with its own sharp corners, dull edges, and hidden idiosyncrasies to deal with along the path to packaging happiness. In an attempt to answer the question "How do I install this software and ensure that its dependencies are fulfilled?", some novel solutions have begun to see popular adoption. But a lot of these newer tools and techniques tread the same ground as their predecessors while overlooking the lessons that were learned along the way.
I'll talk about the state of native packaging systems on some popular platforms (Debian/Ubuntu, RHEL/CentOS/Fedora, and Mac OS X), packaging systems for popular languages (Ruby, Python, Perl, and Node) and the ways that developers are attempting to work around the limitations of these systems. I'll review the reasons that tools like curlbash, FPM, and omnibus packages have become popular by sharing lessons I've learned while working through these systems. While this will be an amusing presentation, I'll show how native packages can address the concerns that have pushed Release Engineers and Developers away. I will also talk about what native packaging systems can learn from the next generation of packaging tools.
The original abstract is available here:
https://www.usenix.org/conference/ures14west/summit-program/presentation/mckern
There are many fast data stores, and then there is Redis. Learn about this excellent NoSQL solution that is a powerful in-memory key-value store. Learn how to solve traditionally difficult problems with Redis, and how you can benefit from 100,000 reads/writes a second on commodity hardware. We’ll discuss how and when to use the different datatypes and commands to fit your needs. We’ll discuss the different PHP libraries with their pros and cons. We’ll then show some live examples on how to use it for a chatroom, and how Redis manages a billion data points for our dating matching system. Finally, we’ll discuss some of the upcoming features in the near future, such as clustering and scripting.
Packaging is the Worst Way to Distribute Software, Except for Everything Elsemckern
As part of the 2014 USENIX Release Engineering Summit West, I presented a talk about packaging software and what's wrong with current trends.
Here's the abstract:
Reliably distributing software is a notoriously difficult problem, and almost every operating system and programming language vendor has tried to solve it. This has led to a herd of packaging systems, almost none of which are cross-compatible; some manage system-level software, while others focus on extending their own language (often by trampling on system-level software). And like all competing standards, every packaging system comes with its own sharp corners, dull edges, and hidden idiosyncrasies to deal with along the path to packaging happiness. In an attempt to answer the question "How do I install this software and ensure that its dependencies are fulfilled?", some novel solutions have begun to see popular adoption. But a lot of these newer tools and techniques tread the same ground as their predecessors while overlooking the lessons that were learned along the way.
I'll talk about the state of native packaging systems on some popular platforms (Debian/Ubuntu, RHEL/CentOS/Fedora, and Mac OS X), packaging systems for popular languages (Ruby, Python, Perl, and Node) and the ways that developers are attempting to work around the limitations of these systems. I'll review the reasons that tools like curlbash, FPM, and omnibus packages have become popular by sharing lessons I've learned while working through these systems. While this will be an amusing presentation, I'll show how native packages can address the concerns that have pushed Release Engineers and Developers away. I will also talk about what native packaging systems can learn from the next generation of packaging tools.
The original abstract is available here:
https://www.usenix.org/conference/ures14west/summit-program/presentation/mckern
There are many fast data stores, and then there is Redis. Learn about this excellent NoSQL solution that is a powerful in-memory key-value store. Learn how to solve traditionally difficult problems with Redis, and how you can benefit from 100,000 reads/writes a second on commodity hardware. We’ll discuss how and when to use the different datatypes and commands to fit your needs. We’ll discuss the different PHP libraries with their pros and cons. We’ll then show some live examples on how to use it for a chatroom, and how Redis manages a billion data points for our dating matching system. Finally, we’ll discuss some of the upcoming features in the near future, such as clustering and scripting.
Drupal powers many small-to-medium websites, from personal blogs to company intranets. Drupal also powers big sites like The Economist and The White House. How are the big sites different from the small ones? What are the main issues to consider when adopting Drupal for the enterprise? What skillset do developers need to build them?
An introduction to the the who, what, why when and how of Drush, the command line utility for Drupal. Presentation given at the Sacramento Drupal Users Group meeting on 6/15/2011
DevOps for Drupal: Why We Cook With ChefPromet Source
DevOps for Drupal presentation given at DrupalCon 2013 in Portland. Promet Source shares secrets for automation and how to make your infrastructure hum.
Continuous Integration, the minimum viable productJulian Simpson
What does it mean to 'do' Continuous Integration? It used to be enough to execute your unit tests in CI. But the bar is steadily raising for engineering practices. In the last decade we've seen tremendous improvements inacceptance testing. JavaScript is now a platform in it's own right. Cloudcomputing is now vital. There's growing interest in deployment to prod.So Continuous Integration is under more pressure than ever. As the bar slowly raises for engineering practices, we ll present 2011's minimum viable feature set for Continuous Integration
Docker landed almost two years ago, making it possible to build, ship, and run
any Linux application, on any platform, it was quickly adopted by developers
and ops, like no other tool before. The CI/CD industry even took it to
production long before it was stamped "production-ready."
Why does everyone (or almost!) love Docker? Because it puts powerful
automation abilities within the hands of normal developers. Automation
almost always involves building distribution packages, virtual machine
images, or writing configuration management manifests. With Docker,
those tasks are radically transformed: sometimes they're far easier than before,
other times they're no longer needed at all. Either way, the intervention
of a seasoned sysadmin guru is no longer required.
Beyond TDD: Enabling Your Team to Continuously Deliver SoftwareChris Weldon
Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?
Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.
DevOpsDays Baltimore 2017.
In high security environments, we are often behind proxies, firewalls or obnoxious corporate policies that disallow access to Github or RubyGems. What gives?! In this session, I will talk about what problems we need to solve to build and manage environments in an offline world and how infrastructure as code is at the heart of making it happen.
In high security environments, we are often behind proxies, firewalls or obnoxious corporate policies that disallow access to Github or RubyGems. What gives?! In this session, I will talk about what problems we need to solve to build and manage environments in an offline world and how infrastructure as code is at the heart of making it happen.
Deploying your Drupal site, Upgrading your Drupal Site, Scaling, Clustering and Monitoring it ... all topics Developers are often not involved with ...
Devops For Drupal explains the Devops problem, to a Drupal audience .
Queues can provide parallel processing, cross language scripting and more! The talk was focused on Gearman but the principles apply to any alternative.
Whats wrong with postgres | PGConf EU 2019 | Craig KerstiensCitus Data
Postgres is a powerful database, it continues to improve in terms of performance, extensibility, and more broadly in features. However it is not perfect.
Here I'll cover a highly opinionated view of all the areas Postgres falls flat, with some rough thought ideas on how we can make it better. Opinions are all informed by 10 years of interacting with customers running literally millions of databases for users.
Four Kitchens Presents: Future of the CMSFour Kitchens
In our "Future of the CMS" webinar, Four Kitchens CEO and Co-Founder Todd Ross Nienkerk walks you through the options behind a modern, responsive, design strategy. Watch the video to learn about:
* Decoupling your CMS
* Multichannel publishing
* Content-as-a-service
* Future-proofing your project
And more!
Four Kitchens has been featured in Forbes, Entrepreneur, Inc., BetaNews, Texas CEO, and Texas Tech Pulse to name a few. We were named one of the "Best places to work in Central Texas" by the Austin Business Journal in 2014 and 2015, and I was a finalist for the Austin Under 40 Awards in 2015. Recent awards for client projects include an Emmy, Stevie Award, Davey Award, AVA Award, WebAward, and two Communicator Awards.
Drupal powers many small-to-medium websites, from personal blogs to company intranets. Drupal also powers big sites like The Economist and The White House. How are the big sites different from the small ones? What are the main issues to consider when adopting Drupal for the enterprise? What skillset do developers need to build them?
An introduction to the the who, what, why when and how of Drush, the command line utility for Drupal. Presentation given at the Sacramento Drupal Users Group meeting on 6/15/2011
DevOps for Drupal: Why We Cook With ChefPromet Source
DevOps for Drupal presentation given at DrupalCon 2013 in Portland. Promet Source shares secrets for automation and how to make your infrastructure hum.
Continuous Integration, the minimum viable productJulian Simpson
What does it mean to 'do' Continuous Integration? It used to be enough to execute your unit tests in CI. But the bar is steadily raising for engineering practices. In the last decade we've seen tremendous improvements inacceptance testing. JavaScript is now a platform in it's own right. Cloudcomputing is now vital. There's growing interest in deployment to prod.So Continuous Integration is under more pressure than ever. As the bar slowly raises for engineering practices, we ll present 2011's minimum viable feature set for Continuous Integration
Docker landed almost two years ago, making it possible to build, ship, and run
any Linux application, on any platform, it was quickly adopted by developers
and ops, like no other tool before. The CI/CD industry even took it to
production long before it was stamped "production-ready."
Why does everyone (or almost!) love Docker? Because it puts powerful
automation abilities within the hands of normal developers. Automation
almost always involves building distribution packages, virtual machine
images, or writing configuration management manifests. With Docker,
those tasks are radically transformed: sometimes they're far easier than before,
other times they're no longer needed at all. Either way, the intervention
of a seasoned sysadmin guru is no longer required.
Beyond TDD: Enabling Your Team to Continuously Deliver SoftwareChris Weldon
Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?
Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.
DevOpsDays Baltimore 2017.
In high security environments, we are often behind proxies, firewalls or obnoxious corporate policies that disallow access to Github or RubyGems. What gives?! In this session, I will talk about what problems we need to solve to build and manage environments in an offline world and how infrastructure as code is at the heart of making it happen.
In high security environments, we are often behind proxies, firewalls or obnoxious corporate policies that disallow access to Github or RubyGems. What gives?! In this session, I will talk about what problems we need to solve to build and manage environments in an offline world and how infrastructure as code is at the heart of making it happen.
Deploying your Drupal site, Upgrading your Drupal Site, Scaling, Clustering and Monitoring it ... all topics Developers are often not involved with ...
Devops For Drupal explains the Devops problem, to a Drupal audience .
Queues can provide parallel processing, cross language scripting and more! The talk was focused on Gearman but the principles apply to any alternative.
Whats wrong with postgres | PGConf EU 2019 | Craig KerstiensCitus Data
Postgres is a powerful database, it continues to improve in terms of performance, extensibility, and more broadly in features. However it is not perfect.
Here I'll cover a highly opinionated view of all the areas Postgres falls flat, with some rough thought ideas on how we can make it better. Opinions are all informed by 10 years of interacting with customers running literally millions of databases for users.
Four Kitchens Presents: Future of the CMSFour Kitchens
In our "Future of the CMS" webinar, Four Kitchens CEO and Co-Founder Todd Ross Nienkerk walks you through the options behind a modern, responsive, design strategy. Watch the video to learn about:
* Decoupling your CMS
* Multichannel publishing
* Content-as-a-service
* Future-proofing your project
And more!
Four Kitchens has been featured in Forbes, Entrepreneur, Inc., BetaNews, Texas CEO, and Texas Tech Pulse to name a few. We were named one of the "Best places to work in Central Texas" by the Austin Business Journal in 2014 and 2015, and I was a finalist for the Austin Under 40 Awards in 2015. Recent awards for client projects include an Emmy, Stevie Award, Davey Award, AVA Award, WebAward, and two Communicator Awards.
Don't Design Websites. Design Web SYSTEMS! (UT Austin Drupal Users Group)Four Kitchens
This presentation was given at the UT Austin Drupal Users Group by Todd Nienkerk of Four Kitchens (June 19, 2012)
For more Four Kitchens presentations, please visit http://fourkitchens.com/presentations
In this session, we will explore the how the recent explosion of devices has disrupted the process of designing a website that we've crafted over the past decade.
When designers only have one instance of website (i.e., desktop) to design, the layout is uniform. The header, content area, sidebar, and footer all remain static. Furthermore, the elements are relatively uniform as well. Buttons, navigation, typography, and images are all basically the same across across the various pages. But if you are designing a responsive website – one whose look and feel adapts depending whether you're using a phone, laptop, or tablet – then these elements and especially the layout begin to diverge.
After this session, you should leave with the confidence to argue the importance of responsive design to your client or boss – and that the with the proper strategy, the extra effort and costs can be justified (and hopefully minimized).
Don't Design Websites. Design Web SYSTEMS! (BADCamp 2011)Four Kitchens
This presentation was given at BADCamp by Todd Nienkerk of Four Kitchens (October 23, 2011)
For more Four Kitchens presentations, please visit http://fourkitchens.com/presentations
Don't Design Websites. Design Web SYSTEMS! (DrupalCon London 2011)Four Kitchens
This presentation was given at DrupalCon London by Todd Nienkerk of Four Kitchens and Adam Snetman of Thinkso Creative (August 24, 2011)
For more Four Kitchens presentations, please visit http://fourkitchens.com/presentations
Don't Design Websites. Design Web SYSTEMS! (DrupalCamp LA 2011)Four Kitchens
This presentation was given at DrupalCamp LA by Todd Nienkerk of Four Kitchens (August 7, 2011)
For more Four Kitchens presentations, please visit http://fourkitchens.com/presentations
Don't Design Websites. Design Web SYSTEMS! (Dallas Drupal Days 2011)Four Kitchens
This presentation was given at Dallas Drupal Days by Aaron Stanush and Todd Nienkerk of Four Kitchens (July 8, 2011)
For more Four Kitchens presentations, please visit http://fourkitchens.com/presentations
You know how to use Drupal. You know how to write code, build a theme, and SEO a site. But do you know how to teach others to use Drupal? For every site we create there are clients who must use it, many don't know a node from a block. After this session, you will be able to introduce clients to Drupal without freaking them out.
We'll cover:
* Defining "need to know" and emphasizing main concepts
* Thinking like a user, talking like a mentor
* Using normal words with a sprinkling of Drupalese
* Breaking down tasks keeping each user's personality and background in mind
* Translating "my site's broken" into a useful and respectful response
* How to think like a non-geek (for a few minutes)
A talk about how far fonts have come on the web and why this is the beginning of a new age for using beautiful fonts everywhere.
Originally presented by Aaron Stanush (Four Kitchens) and Kevin O'Leary (Acquia) at DrupalCon Chicago 2010.
http://chicago2011.drupal.org/sessions/type-revolutionary-s-cookbook
Don't Design Websites. Design Web SYSTEMS! (DrupalCamp Stockholm 2011)Four Kitchens
This presentation was given at DrupalCamp Stockholm by Todd Nienkerk of Four Kitchens (May 7, 2011)
For more Four Kitchens presentations, please visit http://fourkitchens.com/presentations
Don't Design Websites. Design Web SYSTEMS! (DrupalCon Chicago 2011)Four Kitchens
This presentation was given at DrupalCon Chicago by Todd Nienkerk of Four Kitchens and Adam Snetman of Thinkso Creative (March 9, 2011)
For more Four Kitchens presentations, please visit http://fourkitchens.com/presentations
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
3. Drush
”Drush is a command line shell and Unix scripting
interface for Drupal, a veritable Swiss Army knife
designed to make life easier for those of us who
spend some of our working hours hacking away at
the command prompt.”
DrupalCamp Austin 2010
4. Drush
”Drush is a command line shell and Unix scripting
interface for Drupal, a veritable Swiss Army knife
designed to make life easier for those of us who
spend some of our working hours hacking away at
the command prompt.”
Know what that means? Me neither.
DrupalCamp Austin 2010
8. You should be here if
• You don’t know what drush does.
9. You should be here if
• You don’t know what drush does.
• You know what drush does but haven't used it,
much.
10. You should be here if
• You don’t know what drush does.
• You know what drush does but haven't used it,
much.
• You don't break out in hives when someone says
"command line".
11. You should be here if
• You don’t know what drush does.
• You know what drush does but haven't used it,
much.
• You don't break out in hives when someone says
"command line".
• You do break out in hives but must use it anyway.
12. You should be here if
• You don’t know what drush does.
• You know what drush does but haven't used it,
much.
• You don't break out in hives when someone says
"command line".
• You do break out in hives but must use it anyway.
• You've installed a Drupal site and added modules,
like CCK or Views.
13. You should be here if
• You don’t know what drush does.
• You know what drush does but haven't used it,
much.
• You don't break out in hives when someone says
"command line".
• You do break out in hives but must use it anyway.
• You've installed a Drupal site and added modules,
like CCK or Views.
• You are a New England Patriots fan.
15. You should not be here if
• You know what “drush fu” means and when to type
it.
16. You should not be here if
• You know what “drush fu” means and when to type
it.
• You use drush for many common tasks already.
17. You should not be here if
• You know what “drush fu” means and when to type
it.
• You use drush for many common tasks already.
• You heckle.
18. You should not be here if
• You know what “drush fu” means and when to type
it.
• You use drush for many common tasks already.
• You heckle.
• You are a Colts fan.
20. Why I rejected drush
• I went to a presentation and thought, “I can do all
of this already, without the learning curve.”
21. Why I rejected drush
• I went to a presentation and thought, “I can do all
of this already, without the learning curve.”
• I was intimidated by the setup process.
22. Why I rejected drush
• I went to a presentation and thought, “I can do all
of this already, without the learning curve.”
• I was intimidated by the setup process.
• I wasn’t using the command line as much back
then. Unfortunately.
23. Why I rejected drush
• I went to a presentation and thought, “I can do all
of this already, without the learning curve.”
• I was intimidated by the setup process.
• I wasn’t using the command line as much back
then. Unfortunately.
• A few things were kinda cool but kinda cool is not
a reason to adopt new technology.
24. Why I rejected drush
• I went to a presentation and thought, “I can do all
of this already, without the learning curve.”
• I was intimidated by the setup process.
• I wasn’t using the command line as much back
then. Unfortunately.
• A few things were kinda cool but kinda cool is not
a reason to adopt new technology.
• Really.
26. Why I <3 drush now
• I worked in larger environments where doing
things administratively or with FTP wasn’t possible.
Thus discovering the error of my ways.
27. Why I <3 drush now
• I worked in larger environments where doing
things administratively or with FTP wasn’t possible.
Thus discovering the error of my ways.
• I can admit when I’m wrong. Usually.
28. Why I <3 drush now
• I worked in larger environments where doing
things administratively or with FTP wasn’t possible.
Thus discovering the error of my ways.
• I can admit when I’m wrong. Usually.
• I was trained by James Sansbury (g0rban) to use it
more skillfully.
29. Why I <3 drush now
• I worked in larger environments where doing
things administratively or with FTP wasn’t possible.
Thus discovering the error of my ways.
• I can admit when I’m wrong. Usually.
• I was trained by James Sansbury (g0rban) to use it
more skillfully.
• My team created custom drush commands - the
proverbial straw.
31. Why you should use it
• It’s easier. And life is hard enough.
32. Why you should use it
• It’s easier. And life is hard enough.
• It’s faster, which means more time for watching
football.
33. Why you should use it
• It’s easier. And life is hard enough.
• It’s faster, which means more time for watching
football.
• Better command-line skills == a better, more
confident developer. Iow, it feels good.
34. Why you should use it
• It’s easier. And life is hard enough.
• It’s faster, which means more time for watching
football.
• Better command-line skills == a better, more
confident developer. Iow, it feels good.
• Command-line tasks are more repeatable and
(many are) undoable - you have a history.
35. Why you should use it
• It’s easier. And life is hard enough.
• It’s faster, which means more time for watching
football.
• Better command-line skills == a better, more
confident developer. Iow, it feels good.
• Command-line tasks are more repeatable and
(many are) undoable - you have a history.
• You will (probably) have to know how to use it
someday (soon). You will want to use drush 4.
41. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
42. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
43. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
44. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
• Run cron.
45. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
• Run cron.
• Disable and uninstall modules.
46. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
• Run cron.
• Disable and uninstall modules.
• Database tasks (sql-dump, sql-cli).
47. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
• Run cron.
• Disable and uninstall modules.
• Database tasks (sql-dump, sql-cli).
• Set variables (vget, vset).
48. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
• Run cron.
• Disable and uninstall modules.
• Database tasks (sql-dump, sql-cli).
• Set variables (vget, vset).
• Revert or update features.
49. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
• Run cron.
• Disable and uninstall modules.
• Database tasks (sql-dump, sql-cli).
• Set variables (vget, vset).
• Revert or update features.
• Create dummy content or users.
50. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
• Run cron.
• Disable and uninstall modules.
• Database tasks (sql-dump, sql-cli).
• Set variables (vget, vset).
• Revert or update features.
• Create dummy content or users.
• Makefiles (custom installation profiles).
51. Common drush tasks
• Install Drupal.
• Install, enable, and update modules and themes.
• Run update.php.
• Clear the cache.
• Run cron.
• Disable and uninstall modules.
• Database tasks (sql-dump, sql-cli).
• Set variables (vget, vset).
• Revert or update features.
• Create dummy content or users.
• Makefiles (custom installation profiles).
• Custom tasks you create.
53. Which drush
• Drush is constantly evolving, so the version you
install dictates what you can (and can not) do with it.
54. Which drush
• Drush is constantly evolving, so the version you
install dictates what you can (and can not) do with it.
• Not all commands work on all versions of Drupal.
55. Which drush
• Drush is constantly evolving, so the version you
install dictates what you can (and can not) do with it.
• Not all commands work on all versions of Drupal.
• Drush requires PHP version 5.2 or better.
56. Which drush
• Drush is constantly evolving, so the version you
install dictates what you can (and can not) do with it.
• Not all commands work on all versions of Drupal.
• Drush requires PHP version 5.2 or better.
• We are installing drush 3.
57. Which drush
• Drush is constantly evolving, so the version you
install dictates what you can (and can not) do with it.
• Not all commands work on all versions of Drupal.
• Drush requires PHP version 5.2 or better.
• We are installing drush 3.
• We are installing drush on a Linux server. We <3
Linux servers. Same procedure for Mac. Windows
instructions are in the README.txt file.
61. Terminal tools
• On MacOS, you can just open a terminal window.
• We use Coda and it has a built-in terminal.
62. Terminal tools
• On MacOS, you can just open a terminal window.
• We use Coda and it has a built-in terminal.
• If you (must) use a PC, you can use cygwin or
PuTTy (much better than cmd.exe and installing ssh
client.)
63. Terminal tools
• On MacOS, you can just open a terminal window.
• We use Coda and it has a built-in terminal.
• If you (must) use a PC, you can use cygwin or
PuTTy (much better than cmd.exe and installing ssh
client.)
• If you use Linux, you probably know how to do this
already.
67. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
68. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
69. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
70. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
71. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
• Get it: wget http://somewhere.com/file.tar.gz
72. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
• Get it: wget http://somewhere.com/file.tar.gz
• Unpack it: tar xvf
73. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
• Get it: wget http://somewhere.com/file.tar.gz
• Unpack it: tar xvf
• Change permissions: chmod
74. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
• Get it: wget http://somewhere.com/file.tar.gz
• Unpack it: tar xvf
• Change permissions: chmod
• Remove *caution*: rm
75. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
• Get it: wget http://somewhere.com/file.tar.gz
• Unpack it: tar xvf
• Change permissions: chmod
• Remove *caution*: rm
• Link it: ln -s
76. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
• Get it: wget http://somewhere.com/file.tar.gz
• Unpack it: tar xvf
• Change permissions: chmod
• Remove *caution*: rm
• Link it: ln -s
• Move: mv and Copy: cp
77. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
• Get it: wget http://somewhere.com/file.tar.gz
• Unpack it: tar xvf
• Change permissions: chmod
• Remove *caution*: rm
• Link it: ln -s
• Move: mv and Copy: cp
• Complete file name: tab
78. Common commands
• Log in: ssh username@example.com
• (a note about keys)
• Look inside: ls
• Go into: cd /directory
• Go up: cd ..
• Let me do important stuff: sudo
• Get it: wget http://somewhere.com/file.tar.gz
• Unpack it: tar xvf
• Change permissions: chmod
• Remove *caution*: rm
• Link it: ln -s
• Move: mv and Copy: cp
• Complete file name: tab
83. Installing drush
• Go to the directory you want drush to live in: cd /
usr/local/share/
84. Installing drush
• Go to the directory you want drush to live in: cd /
usr/local/share/
• Get drush: [sudo] wget http://ftp.drupal.org/files/
projects/drush-6.x-3.3.tar.gz
85. Installing drush
• Go to the directory you want drush to live in: cd /
usr/local/share/
• Get drush: [sudo] wget http://ftp.drupal.org/files/
projects/drush-6.x-3.3.tar.gz
• Unpack it: tar xvf drush-6.x-3.3.tar.gz
86. Installing drush
• Go to the directory you want drush to live in: cd /
usr/local/share/
• Get drush: [sudo] wget http://ftp.drupal.org/files/
projects/drush-6.x-3.3.tar.gz
• Unpack it: tar xvf drush-6.x-3.3.tar.gz
• Remove the package: rm drush-6.x-3.3.tar.gz
87. Installing drush
• Go to the directory you want drush to live in: cd /
usr/local/share/
• Get drush: [sudo] wget http://ftp.drupal.org/files/
projects/drush-6.x-3.3.tar.gz
• Unpack it: tar xvf drush-6.x-3.3.tar.gz
• Remove the package: rm drush-6.x-3.3.tar.gz
• Change permissions: chmod u+x drush
88. Installing drush
• Go to the directory you want drush to live in: cd /
usr/local/share/
• Get drush: [sudo] wget http://ftp.drupal.org/files/
projects/drush-6.x-3.3.tar.gz
• Unpack it: tar xvf drush-6.x-3.3.tar.gz
• Remove the package: rm drush-6.x-3.3.tar.gz
• Change permissions: chmod u+x drush
• Create a link: ln -s /usr/local/share/drush/drush /
usr/local/bin/drush
89. Installing drush
• Go to the directory you want drush to live in: cd /
usr/local/share/
• Get drush: [sudo] wget http://ftp.drupal.org/files/
projects/drush-6.x-3.3.tar.gz
• Unpack it: tar xvf drush-6.x-3.3.tar.gz
• Remove the package: rm drush-6.x-3.3.tar.gz
• Change permissions: chmod u+x drush
• Create a link: ln -s /usr/local/share/drush/drush /
usr/local/bin/drush
• Run drush: [sudo] drush
93. Installing Drupal
• Create a database in your usual way.
• cd path/to/webroot (often this is www)
• drush dl
94. Installing Drupal
• Create a database in your usual way.
• cd path/to/webroot (often this is www)
• drush dl
• mv drupal-6.XX drupal
95. Installing Drupal
• Create a database in your usual way.
• cd path/to/webroot (often this is www)
• drush dl
• mv drupal-6.XX drupal
• (notes on where to put files)
96. Installing Drupal
• Create a database in your usual way.
• cd path/to/webroot (often this is www)
• drush dl
• mv drupal-6.XX drupal
• (notes on where to put files)
• drush site-install --db-url=mysql://
root:pass@localhost:port/dbname
97. Installing Drupal
• Create a database in your usual way.
• cd path/to/webroot (often this is www)
• drush dl
• mv drupal-6.XX drupal
• (notes on where to put files)
• drush site-install --db-url=mysql://
root:pass@localhost:port/dbname
• Unfortunately, that only works in Drupal 7.
101. Installing Views and CCK
• cd into your drupal directory
• drush dl cck views
• drush en views content
102. Installing Views and CCK
• cd into your drupal directory
• drush dl cck views
• drush en views content
• Brilliant drush will put them in your sites/all/
modules directory.
103. Installing Views and CCK
• cd into your drupal directory
• drush dl cck views
• drush en views content
• Brilliant drush will put them in your sites/all/
modules directory.
• Let’s watch Aaron do it.