I just migrated my blog(s) to WordPress.
Just recently I decided to put more time into blogging again. I wasn’t entirely happy with Movable Type anymore, especially since the last update broke my customized theme and I struggled with the installation of another theme, which basically just were never found, no matter which path I put it into.
What I wanted is just more blogging, not all that technical stuff. And since the Movable Type makers also seem to have gone crazy (their “Getting started” site tells users to head over to movabletype.com to get a 999$ license) I decided to get back to WordPress.
There were reasons, why I haven’t chosen WordPress back when I migrated from blogger to MT, but one has to say anyway, that things have moved a lot since then. And WordPress is as easy as it can be and has a prosper community, something I cannot say about MovableType.
The migration went okay, although there were some oddities in the blog entries exported by MT (e.g. datetime strings with EM and FM at the EOL) and I need to figure out how the multisite feature in WordPress works. But now I have exactly what I want.
For this release cycle, I have uploaded two new packages:
- dtv-scan-tables - Digital Video Broadcasting (DVB) initial scan files
- This is a new package which splits out the DVB initial scan files from linux-dvb-apps (see below). This is designed to make updating of the scan files easier.
- git-remote-hg - bidirectional bridge between Git and Mercurial
- This is a new package which allows a Git client to read and write to Mercurial repositories. Previously provided as an example in the Git package until removed by upstream.
I've also have taken over as (co-)maintainer of some existing packages during this release cycle:
- linuxtv-dvb-apps - Digital Video Broadcasting (DVB) applications
- New upstream snapshot, split out DVB initial scan files into dtv-scan-files package (see above), enable hardened buildflags.
I've updated nearly all of my existing packages during this release cycle:
- dhex - ncurses based hex editor with diff mode
- New upstream release, various packaging fixes.
- lcd4linux - Grabs information and displays it on an external lcd
- New upstream snapshot, add systemd service file, install dummy config file which resolves issues on certain upgrades.
- libconfig - Parsing and manipulation of structured configuration files
- New upstream release, various packaging fixes.
- nyancat - nyancat is a program to display an animated poptart cat in your terminal
- New upstream release; Nyancat now resizes to fix the terminal!
- transmission-remote-cli - ncurses interface for the Transmission BitTorrent daemon
- New upstream release, support new versions of Transmission, various bug and packaging fixes.
- wavemon - Wireless Device Monitoring Application
- New upstream release, various bug and packaging fixes, fix FTBFS on arm64.
The following package received no updates during this release cycle due to a combination of no upstream releases and the existing package already being in good shape:
- figlet - Make large character ASCII banners out of ordinary text
I hope you find them useful. Enjoy!
So, what’s Yeoman then? It’s a code scaffolding tool. That is, it’s an utility to generate code for web apps. What’s the purpose of that? Well, the purpose is that developers save time by quickly generating the skeleton of the web apps they build, leaving more time for the important things, such as the most complex business logic of the app, integrations, testing, etc… In short: it’s a tool that should help developers deliver more quality in their apps. To get a better picture of what Yeoman can do, I’d point everyone at their site, which has some nice tutorials and a very good documentation for writing your own generators.
My plan was to write a few generators for the most common pieces of boilerplate code that I normally have to write in my projects. Unsurprisingly, I found that there are a few yeoman generators for Drupal already out there, so I thought I should review them and see if they’re of any use to me, before writing one that already exists. Yes, that can be a boring task if there are too many generators, but I was lucky that there aren’t *that* many for Drupal, so I just spent a couple of hours testing them and documenting my findings. Hopefully, this blog post will help other Drupal developers to find out in a matter of minutes whether the existing generators are useful for them or not. So, let’s get into it!1.- Generator-drupalmodule
Github repository here. Creation date: Around 2 years ago.
Structure created:module: |- drupalmodule.css |- drupalmodule.info |- drupalmodule.js |- drupalmodule.module |- package.json
This one scaffolds a basic structure for a simple module. Needs bower and a package.json file to download dependencies, but not a problem anyway since you’ll probably have drush. Creation is a bit unintuitive: you need to create the module folder first, cd into it, then execute yo drupalmodule.
The generator asks if you want JS and CSS files, but it doesn’t even add functions to add them to the page. It’s a generic purpose generator, and doesn’t have anything that is not in module_builder already.2.- Generator-drupal-module
Github repository here. Creation date: Around 2 months ago. Latest commit about 2 weeks ago.
Structure created:module: |- templates (if hook_theme chosen). |- drupal_module.info |- drupal_module.install |- drupal_module.module
More neat than drupalmodule in the surface, but doesn’t do much more. It asks us if we want hook_theme(), hook_menu(), hook_permission() and hook_block_info / view implementations, which is nice, yet that doesn’t make it much of a gain compared to other simple scaffolding tools, like PhpStorm live templates. In contrast to the drupal-module generator, this one doesn’t ask us if we want a CSS or JS file.3.- Generator-drupalentities
Github repository here. Creation date: 9 months ago. Latest commit about 6 months ago.
Structure created (“publisher” entity):
Views and license files are optional, based on the settings specified in the command-line.module: |- views |- publisher.views.inc |- publisher_handler_delete_link_field.inc |- publisher_handler_edit_link_field.inc |- publisher_handler_link_field.inc |- publisher_handler_publisher_operations_field.inc |- LICENSE.txt |- publisher.admin.inc |- publisher.info |- publisher.install |- publisher.module |- publisher.tpl.php |- publisher-sample-data.tpl.php |- publisher_type.admin.inc
Generates a full drupal module for a custom entity, based on the structure proposed by the model module.
One issue I experienced is that if I select to “add bundles”, the Field API screen seems broken (doesn’t load). However, a general “fields” tab appears, but if you try to add a field, you get some errors and get redirected to a 404. So, bundles are offered on the plugin creation menu, but not really supported! Same for revisions. It’s asked on the command-line prompt, but doesn’t seem to do much. Not choosing bundles support, still lets you add bundles on the admin UI, and doesn’t seem to break anything, though.
In spite of the issues I had testing it (I didn’t bother much investigating what was the issue), it seems to me an useful generator. The only reason why I doubt I’ll be using it, is that it’s based, as mentioned, on the model project for Drupal, which is quite nice, but rather outdated now (4 years old), and doesn’t leverage some of the latest Entity API goodies. Also, I’ve developed some opinions and preferences around how to structure custom Entity Types, so starting to use the model approach would be, in a sense, a step backwards.4.- Generator-ctools-layout
Github repository here. Creation date: 5 months ago. Latest commit about 14 days ago.
Structure created:my_layout: |- admin_my_layout.css |- my_layout.css |- my_layout.inc |- my_layout.png |- my-layout.tpl.php
Generates a ctools layout plugin folder structure, with all the files needed to get it to work out of the box. It makes no assumptions about how the content will be displayed, so there’s no styling by default (which is perfect), and it allows to specify as many regions as desired. It’s quite likely that I start using this in my projects. No cons or negative aspects to mention!5.- Generator-gadget
Github repository here. Creation date: 1 month ago. Latest commit about 1 month ago.
This one, rather than a code generator for Drupal elements, is a yeoman generator to serve as an scaffolding tool for another repo from Phase 2. While I didn’t get to test it out, the grunt-drupal-tasks repo really looked interesting (check the features here), and I might try to give that a go, although I’m familiar with Gulp and not with Grunt. Long story short: very interesting project, but it’s not meant to scaffold any code for your drupal modules.6.- Generator-drupalformat
Github repository here. Creation date: 6 months ago. Latest commit about 3 months ago.
Structure created:drupalformat: |- includes |- js |- drupalformat.settings.js |- theme |- drupalformat.theme.inc |- drupalformat.tpl.php |- drupalformat.api.php |- drupalformat.info |- drupalformat.install |- drupalformat.module |- drupalformat.variable.inc |- generator.json |- LICENSE.txt
Github repository here. Creation date: 6 months ago. Latest commit about 3 months ago.
Structure created:drupal_component: |- ctools-content_types |- drupal_component.inc |- drupal_component.scss |- drupal_component.html.twig |- drupal_component.info |- drupal_component.js |- drupal_component.module |- drupal_component.tpl.php |- drupal_component.views.inc
I found this one rather peculiar. The boilerplate code it produces is rather basic, yet offers options such as creating a views style plugin by default, or a ctools content_type plugin. The good thing is that each component can be generated individually, which is rather convenient. The only issue that keeps me from using it is that, again, none of the components offer any options particularly advanced that could benefit from having an interactive tool like Yeoman (e.g: asking whether the ctools content type plugin will need one or more settings forms). For my particular case, I can generate all of these easily with PhpStorm live templates or template files easily.Is that all, folks?
Ye… no! There are indeed a few more generators thought around drupal projects in the Yeoman registry (click here and search by “Drupal”). Some of them are very interesting, to do things such as:
- Scaffold a headless Drupal backend with Angular, or a headless Drupal backend with Backbone Marionette.
- Generate a Drupal theme, or another Drupal theme, or YET another Drupal theme.
- Scaffold a whole development stack for Drupal.
However, I decided to leave those out of an in-depth review because, as interesting as they are, they cover several aspects of Drupal development, and people often has very specific preferences about how to structure a theme, for example, or what tools to use in order to create a Headless Drupal.
Since the goal of this article was to give a bird’s eye view of what generators Drupal developers can use right now without changing anything in the way they work, I preferred to describe mainly the generators done around drupal modules, and more specific components. Hope this blog post has saved you some time. Expect to see a new one on this topic as soon as I’ve written my first Yeoman plugin.
Release day is a nerve-wracking time for several teams. Happily we’ve done it a few times now, so we have a rough idea of how the process should go.
There have been some preparations going on in advance:
- Last week we imposed a “quiet period” on migrations. That’s about as frozen as we can get; it means that even RC bugs need to be exceptional if they aren’t to be deferred to the first point release. Only late-breaking documentation (like the install guide) was accepted.
- The security team opened jessie-updates for business, carried out a test upload, and have since released several packages so that those updates are available immediately after release.
- The debian-installer team made a final release.
- Final debtags data was updated.
- Yesterday the testing migration script britney and other automatic maintenance scripts that the release team run were disabled for the duration.
- We made final preparations of things that can be done in advance, such as drafting the publicity announcements. These have to be done in advance so translators get chance to do their work overnight (the announcement was signed off at 15:30UTC today, translations are starting to arrive right now!).
The following checklist makes the release actually happen:
- Once dinstall is completed at 07:52, archive maintenance is suspended – the FTP masters will do manual work for now.
- Very large quantities of coffee will be prepared all across Europe.
- Release managers carry out consistency checks of the Jessie index files, and confirm to FTP masters that there are no last-minute changes to be made. RMs get a break to make more coffee.
- While they’re away FTP masters begin the process of relabelling Wheezy as oldstable and Jessie as stable. If an installer needs to be, er, installed as well, that happens at this point. Old builds of the installer are removed.
- A new suite for Stretch (Debian 9) is initialised and populated, and labelled testing.
- Release managers check that the newly-generated suite index files look correct and consistent with the checks made earlier in the day. Everything is signed off – both in logistical and cryptographic terms.
- FTP masters trigger a push of all the changes to the CD-building mirror so that production of images can begin. As each image is completed, several volunteers download and test it in as many ways as they can dream up (booting and choosing different paths through the installer to check integrity).
- Finally a full mirror push is triggered by FTP masters, and the finished CD images are published.
- Announcements are sent by the publicity team to various places, and by the release team to the developers at large.
- Archive maintenance scripts are re-enabled.
- The release team take a break for a couple of weeks before getting back into the next cycle.
During the day much of the coordination happens in the #debian-release, #debian-ftp and #debian-cd IRC channels. You’re welcome to follow along if you’re interested in the process, although we ask that you are read-only while people are still concentrating (during the Squeeze release, a steady stream of people turned up to say “congratulations!” at the most critical junctures; it’s not particularly helpful while the process is still going on). The publicity team will be tweeting and denting progress as it happens, so that makes a good overview too.
If everything goes to plan, enjoy the parties!
(Disclaimer: inaccuracies are possible since so many people are involved and there’s a lot to happen in each step; all errors and omissions are entirely mine.)What to expect on Jessie release day is a post from: jwiltshire.org.uk | Flattr
Launching a website is just the beginning of a process. Websites need nurturing and care over the long run to stay relevant and effective. This is even more true for a service or tool such as LibraryEdge.org. Why would users come back if they can only use the provided service once or can’t see progress over time? And how can you put that love and care into the service if it is not self-funded?
This month, LibraryEdge.org released a number of changes to address just these issues.Helping Libraries Stay Relevant
Before we dive into the release, here’s a bit on the Edge Initiative.
With the changes created by modern technology, library systems need a way to stay both relevant and funded in the 21st century. A big part of solving that problem is developing public technology offerings. Even in the internet-connected age, many lower-income households don’t have access to the technology needed to apply to jobs, sign up for health insurance, or file taxes, because they don’t have personal computers and internet connections. So where can people go to use the technology necessary for these and other critical tasks? Libraries help bridge the gap with computers and internet access freely available to the public.
It’s important that libraries stay open and are funded so their resources remain widely available. By helping library systems improve their “public access computers/computing,” the Edge Initiative and its partners have made major strides in making sure libraries continue to be a valuable resource to our society.
That’s where LibraryEdge.org comes in. The Edge Coalition and Forum One built LibraryEdge.org in 2013 as a tool for library systems to self-evaluate their public technology services through a comprehensive assessment – plus a series of tools and resources to help library systems improve their services.New Functionality Reassessment
The biggest feature update we recently launched was enabling libraries to retake the Assessment. They can see how they have improved and where they still need work compared to the previous year. To create a structure around how libraries can retake the Assessment, we built a new feature called Assessment Windows. This structure allows the state accounts to control when the libraries in their states can take the Assessment. States now have control over when their libraries conduct the Assessment and can track their libraries’ goals and progress on Action Items. This feature allows states to more accurately assess the progress of their libraries and adapt their priorities and programming to align with library needs.Results Comparison
The Edge Toolkit was initially built to allow users to view their results online, along with providing downloadable PDF reports so libraries can easily share their results with their state legislatures and other interested parties. Now that libraries can have results for two assessments, we’ve updated the online results view and the PDFs. Libraries can now see a side-by-side comparison of their most recent results with their previous results.Graphs
It’s common knowledge that people retain more of what they see, so we’ve also visualized important pieces of the results data with new graphs. If a library has only taken the assessment once, then the charts will only display its highest and lowest scoring benchmarks. However, if they’ve taken the assessment a second time, they can also see bar graphs for the most improved and most regressed benchmarks.Improved User Experience Interviews
We made a number of enhancements based on feedback from libraries that have been using the tool for the past couple of years, as well as from interviews that we conducted with State Library Administrators. Starting with a series of interviews gave us great insight into how the tool was being used and what improvements were needed.New Navigation
The added functionality of being able to retake the Assessment increased the level of complexity for the Edge Toolkit. So we redesigned the interface to guide users through this complex workflow. We split out the Toolkit into four sections: introduction/preparation, taking the assessment, reviewing your results, and taking action. This new workflow and navigation ensures a user is guided from one step to the next and is able to complete the assessment.Notification Messages
Several dates and statuses affect a library system as they work through the assessment, such as how long they have to take it and whether it is open to be retaken. We’ve implemented notifications that inform the user of this information as they are guided through the workflow.Automated Testing
When we release new features, we need to ensure other components on the site don’t break. Testing this complex of a system can take a long time and will get expensive over the lifetime of the site if it’s done manually. Furthermore, testing some sections or statuses involves taking a long assessment multiple times. In order to increase our efficiency and save time in our quality assurance efforts, we developed a suite of automated tests using Selenium.What’s Next for Edge
The updated LibraryEdge.org now allows libraries to assess their offerings again and again so they can see how they are improving. Additionally, we’ve built a paywall so Edge can be self-supporting and continue to provide this valuable service to libraries after current funding ends. The launch of this updated site will help Edge remain relevant to its users and, therefore, ensure libraries remain relevant to our communities.
Repeating what I did last year with the #newinwheezy game it’s time for the #newinjessie game:
Debian/jessie AKA Debian 8.0 includes a bunch of packages for people interested in digital forensics. The packages maintained within the Debian Forensics team which are new in the Debian/jessie stable release as compared to Debian/wheezy (and ignoring wheezy-backports):
- ext4magic: recover deleted files from ext3 or ext4 partitions
- libbfio1: Library to provide basic input/output abstraction
- lime-forensics-dkms: kernel module to memory dump
- mac-robber: collects data about allocated files in mounted filesystems
- pff-tools: library to access various ms outlook files formats/tools to exports PAB, PST and OST files
- ssdeep: Recursive piecewise hashing tool (note: was present in squeeze but not in wheezy)
- volatility: advanced memory forensics framework
- yara: help to identify and classify malwares
Join the #newinjessie game and present packages which are new in Debian/jessie.
Design work is a lot of show-and-tell. It can be challenging to effectively communicate and collaborate on a distributed team. Join hostess Amber Matz, Lullabot Creative Director Jared Ponchot, Lullabot UX Designer Jen Witkowski, and Justin Harrell, Interactive Designer for Drupalize.Me, as they talk about the unique challenges, processes, and tools they use as part of a distributed team.
At the current rate, Jessie should release... tomorrow! :)
The UDD bugs interface currently knows about the following release critical bugs:
- In Total:
150 bugs affecting
- Affecting Jessie:
66 (key packages:
49) That's the number we need to get down to zero
before the release. They can be split in two big categories:
- Affecting Jessie and unstable:
57 (key packages:
43) Those need someone to find a fix, or to finish the
work to upload a fix to unstable:
- 14 bugs are tagged 'patch'. (key packages: 10) Please help by reviewing the patches, and (if you are a DD) by uploading them.
- 3 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
- 40 bugs are neither tagged patch, nor marked done. (key packages: 33) Help make a first step towards resolution!
- Affecting Jessie only: 9 (key packages: 6) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
- Affecting Jessie and unstable: 57 (key packages: 43) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
- Affecting Jessie: 66 (key packages: 49) That's the number we need to get down to zero before the release. They can be split in two big categories:
How do we compare to the Squeeze and Wheezy release cycles?Week Squeeze Wheezy Jessie 43 284 (213+71) 468 (332+136) 319 (240+79) 44 261 (201+60) 408 (265+143) 274 (224+50) 45 261 (205+56) 425 (291+134) 295 (229+66) 46 271 (200+71) 401 (258+143) 427 (313+114) 47 283 (209+74) 366 (221+145) 342 (260+82) 48 256 (177+79) 378 (230+148) 274 (189+85) 49 256 (180+76) 360 (216+155) 226 (147+79) 50 204 (148+56) 339 (195+144) ??? 51 178 (124+54) 323 (190+133) 189 (134+55) 52 115 (78+37) 289 (190+99) 147 (112+35) 1 93 (60+33) 287 (171+116) 140 (104+36) 2 82 (46+36) 271 (162+109) 157 (124+33) 3 25 (15+10) 249 (165+84) 172 (128+44) 4 14 (8+6) 244 (176+68) 187 (132+55) 5 2 (0+2) 224 (132+92) 175 (124+51) 6 release! 212 (129+83) 161 (109+52) 7 release+1 194 (128+66) 147 (106+41) 8 release+2 206 (144+62) 147 (96+51) 9 release+3 174 (105+69) 152 (101+51) 10 release+4 120 (72+48) 112 (82+30) 11 release+5 115 (74+41) 97 (68+29) 12 release+6 93 (47+46) 87 (71+16) 13 release+7 50 (24+26) 97 (77+20) 14 release+8 51 (32+19) ??? 15 release+9 39 (32+7) 82 (49+17) 16 release+10 20 (12+8) 53 (49+4) 17 release+11 24 (19+5) 66 (57+9) 18 release+12 2 (2+0)
At the time of this writing, just under 300,000 websites use the Drupal Backup and Migrate module. It is an great tool for moving databases from production back to staging and development servers, and it is an essential tool for automatic backups of the database and files of the production server.
About a year ago, Version 3.0 was released, which integrated the offsite functionality from another module, and brought additional functionality, like files and code back ups. This is what I would like to go through today in the steps below.Why offsite backups?
I hope by now everyone has heard of the Backup 3-2-1 Rule. If you haven't, it is a good thing to strive for in all things digital. The rule mentions "In case your house burns down", but in our case, with web servers, there are a lot more risks. The server could get hacked. The developer or client could accidentally delete. The hosting company could go out of business. There are probably a lot more reasons that I sudder to think about!
This is to announce a new upcoming FLOSS project addressing the remote (desktop) computing realm in the GNU/Linux (and possibly other *nices) server world.
The new project's name will be The Arctica Project [1, 2].
In the Arctica Project, 5-6 developers from all over the world have come together to revisit the field of remote (desktop) computing and write a remote computing framework from scratch.
At the moment, there are not many solutions around that (a) are 100% Free Software, (b) work acceptable for most users and (c) also address large scale deployments and enterprise grade customers. To be honest, IMHO there is actually no such solution at all.
The Arctica Project attempts at changing this sustainably; and we are starting with it NOW.
If anyone reads this and gets curious, please join us on IRC and get in touch! If you feel like a potential contributor, we happily invite you to become one. We are open to your input. Please share it. (Thanks!)
 IRC channel #arctica on Freenode
One further contributor became a non-uploading Debian Developer in 2015, joining 11 others who achieved that status its introduction in 2010.
Non-uploading developers are really important to our project. They’re a recognition of the invaluable work that contributors do which doesn’t involve packaging, for which they may not have the skill nor inclination. Nevertheless we would be much weaker without those tireless contributions in the community, translations, bug handling – the list is much longer and covers every aspect of Debian life.
If you’re reading this and thinking “I have a sustained involvement in some aspect of Debian, and make regular contributions”, please consider chatting to those you work with and see if you’re ready to be recognised too.
(source: https://nm.debian.org/public/people#dd)Jessie Countdown: 1 is a post from: jwiltshire.org.uk | Flattr
Why did internet succeed and is growing by incredible pace? Because there were no politicians, no lawyers no economist or managers. Period.
If only non-Finns could easily pronounce it, I think "yhteisöllisyys" would be a perfect motto for Drupal. To explain what it means, I dragged Lauri Eskola, Drupal Craftsman from Druid.fi, away from the contribution sprints at DrupalCamp Brighton 2015 long enough for him to fill me in on that, as well as his trip to Drupal Camp Delhi 2015, what he's excited about in Drupal 8, and how doing business in the Drupal world–based on values like sharing and openness–must seem strange and different to outsiders.
Drupal allows you to easily change the order of your displayed fields using the Manage Display option for your content types but it does not allow you to change the order of the title field (because this field is rendered directly from the node template). But there may be times that you want to display your custom field(s) before the title field. For example, if you have an image field that you want to float to the left of your title and remaining node content.
What happens if you remove randomness from Doom?
For some reason, recently I have been thinking about Doom. This evening I was wanting to explore some behaviour in an old version of Doom and to do so, I hex-edited the binary and replaced the random number lookup table with static values.
Rather than consume system randomness, Doom has a fixed 256-value random number table from which numbers are pulled by aspects of the game logic. By replacing the whole table with a constant value, you essentially make the game entirely deterministic.
What does it play like? I tried two values, 0x00 and 0xFF. With either value, the screen "melt" effect that is used at the end of levels is replaced with a level vertical wipe: the randomness was used to offset each column. Monsters do not make different death noises at different times; only one is played for each category of monster. The bullet-based (hitscan) weapons have no spread at all: the shotgun becomes like a sniper rifle, and the chain-gun is likewise always true. You'd think this would make the super-shotgun a pretty lethal weapon, but it seems to have been nerfed: the spread pattern is integral to its function.
With 0x00, monsters never make their idle noises (breathing etc.) On the other hand, with 0xFF, they always do: so often, that each sample collides with the previous one, and you just get a sort-of monster drone. This is quite overwhelming with even a small pack of monsters.
With 0xFF, any strobing sectors (flickering lights etc.), are static. However, with 0x00, they strobe like crazy.
With 0x00, monsters seem to choose to attack much more frequently than usual. Damage seems to be worst-case. The most damaging floor type ("super hellslime"/20%) can hurt you even if you are wearing a radiation suit: There's a bug in the original game which meant there was a very low chance of it hurting (~2.6%) each time the game checked; this is rounded up to 100%.
Various other aspects of the game become weird. A monster may always choose to use a ranged attack, regardless of how close you are. They might give up pursuing you. I've seen them walk aimlessly in circles if they are obstructed by another thing. The chance of monster in-fighting is either, or a certainty. The player is either mute, or cries in pain whenever he's hurt.
If you want to try this yourself, the easiest way is to hack the m_random.c file in the source, but you can hex-edit a binary. Look for a 256-byte sequence beginning beginning ['0x0', '0x8', '0x6d', '0xdc', '0xde', '0xf1'] and ending ['0x78', '0xa3', '0xec', '0xf9'].
Another month, another swath of work to improve our favorite content management system.The Usual (Contrib) Suspects
Once again some of our main achievements during March was on client-sponsored work, most notably:
Cathy Theys (YesCT), Blackmesh Community Liason and Drupal Community organizer extraordinare, joins Mike Anello and a hybrid Andrew Riley-Ryan Price on this 150th episode of the DrupalEasy podcast. We discussed Drupal code governance, Drupal Dev Days, Drupal 8 progress, DrupalCon Los Angeles, Drupal 8 page caching, and running testbot from the command line. We also brainstormed a new set of 5 questions, learned about Cathy's upcoming travel schedule, listened to Ryan perform the Zelda theme song, and wondered about some listener feedback.
Over the past few months I have been banging my head against a problem at MSNBC: importing the site's extremely large database to my local environment took more than two hours. With a fast internet connection, the database could be downloaded in a matter of minutes, but importing it for testing still took far too long. Ugh!
In this article I'll walk through the troubleshooting process I used to improve things, and the approaches I tried — eventually optimizing the several-hour import to a mere 10-15 minutes.
You’ve heard about it, read about it, and – if you’re like me – dreamed about it. Well, its time to stop dreaming and start doing.
If you have experience building sites using Drupal 7, you’ll be pleased to see that from a site building and administration perspective, things are nearly the same.
And if Drupal 8 is your first Drupal experience, you will be pleasantly surprised at how easy it is to build an amazing site.Installing Drupal
First things first.
You’ll need a basic set of software installed and operational on your laptop, desktop, or server before proceeding with the Drupal 8 installation. Drupal requires that Apache, MySQL, and PHP are installed and working before beginning the installation process. There are several ways to easily install the required software using LAMP (Linux, Apache, MySQL and PHP), WAMP (Windows), or MAMP (Mac) solutions. Grab Google and do a quick search.
Good. Now there are five basic steps to install Drupal:
- Download the latest version of Drupal 8
- Extract the distribution in your Apache
- Create a database to hold the content from the site
- Create the files directory and settings.php
- Run the installation process by visiting your website in a browser
For details on the installation process visit http://wdog.it/4/1/docs.
These are the basic building blocks that will provide the foundation for your Drupal 8 site:
- Content types
If your site is simple and you’re the only one who will be authoring, editing, and managing content, then the admin account you created during the installation process may be all that you need. In situations where you want to share the content creation and management activities with others, you need to create accounts for those users.
Last week, a few coworkers and I went to the Drupal Developer Days in Montpellier. With the main focus being on sprints, contribution to core and on pushing the release of Drupal 8 forward, the Dev Days are a great event for drupalistas to meet the community, share knowledge and work on Drupal.
The DDD was the best drupal related event I’ve been to so far. Its relative small number of attendees - about 300 instead of the 2000+ that attend the european DrupalCons - made it effortless to meet new people. The event was well organised, with good infrastructure and freshly cooked meals every day.
As a site builder interested in contributing more to the community I started the first sprint day in the mentoring sprints learning the best practices for contributing to Drupal. I was surprised at the kindness and patience from the mentors who spend all their time making new members feel welcome at the expense of having fun with their own code and projects.
During the sprints, Josef spent a lot of time motivating people who want to help with the #d8rules initiative - you can read an update here. Emma worked on moving forward Bartik issues as she is the maintainer of the theme. She also mentored and helped people who worked on frontend issues.
After 3 days of sprinting, sessions started on Thursday with a keynote from Angie Byron (webchick) about the Evolution of the Drupal Community. My favorite talk was “Drupal 8 Entity API” by Wolfgang Ziegler (fago) that gave a good overview of the changes in the entity system and the underlying structure on which the whole system is built. It was well presented and clearly structured, so that even non-developers like me understood the topic well.
The Amazee team was well represented at the sessions. Michael (Schnitzel) presented a talk relating Amazee Labs’ accumulated knowledge and experience on multilingual sites in Drupal 7 and the great changes to come to Drupal 8. Drupal Multilingual best practices
Bastian (dasrecht) presented Logfile Handling - Are you visualizing your logfiles? and got great feedback from the community, during the session as well as on social media.
And finally Josef co-presented a session on the rules module Writing plug-ins with #d8rules with Klaus Purer (klausi) and Wolfgang Ziegler (fago). The amount of work that goes into porting a module of that size as well as the changes in structure were explained as well as the methods to port current Rules plugins to D8.
As at every Drupal event, we spend a fair amount of our evenings socialising and discovering the city. Montpellier is a beautiful city although a bit neglected in some areas. The weather was sunny and springier than what we are used to in the north at that time of year, and some crazy folks even dared to go swim in the mediterranean. The Montpelliérains (people from Montpellier) appear to be helpful and accomodating. And to top it all, french food everywhere!
All in all the event was a success personally as well as for the community. In one week, 138 patches were committed to Drupal 8 and by the end of the week only 38 critical bugs remained. You can also find photos on our flickr page .