Newsfeeds

Poll Geolocation

New Drupal Modules - 2 July 2018 - 3:45am

This is a geolocation receiver module who involved in Drupal poll(admin/pollgeolocation/show), this module has some dependencies which Requires:Poll, Field, Node, Text, Filter, User, System, Options, Views.

Categories: Drupal

Drupal Association blog: It's Time To Vote - Community Elections 2018

Planet Drupal - 2 July 2018 - 2:00am

Voting is now open for the 2018 At-Large Board positions for the Drupal Association!  If you haven't yet, check out the candidate profiles including their short videos found on the profile pages. Get to know your candidates, and then get ready to vote.

Cast Your Vote!

How does voting work? Voting is open to all individuals who have a Drupal.org account by the time nominations open and who have logged in at least once in the past year.

To vote, you will rank candidates in order of your preference (1st, 2nd, 3rd, etc.). The results will be calculated using an "instant runoff" method. For an accessible explanation of how instant runoff vote tabulation works, see videos linked in this discussion.

Election voting will be held from 2 July, 2018 through 13 July, 2018. During this period, you can continue to review and comment on the candidate profiles.

Have questions? Please contact me: Rachel Lawson.

Categories: Drupal

Fuzzy Thinking: To Boldly Go ...

RPGNet - 2 July 2018 - 12:00am
Fuzzy fumbles.
Categories: Game Theory & Design

Gizra.com: Using JSON API with WebdriverIO Tests

Planet Drupal - 1 July 2018 - 9:00pm

In Drupal, you can write automated tests with different levels of complexity. If you need to test a single function, or method of a class, probably you will be fine with a unit test. When you need to interact with the database, you can create kernel tests. And finally, if you need access to the final HTML rendered by the browser, or play with some javascript, you can use functional tests or Javascript tests. You can read more about this in the Drupal.org documentation.

So far this is what Drupal provides out of the box. On top of that, you can use Behat or WebDriver tests. This types of tests are usually easier to write and are closer to the user needs. As a side point, they are usually slower than the previous methods.

The Problem.

In Gizra, we use WebdriverIO for most of our tests. This allow us to tests useful things that add value to our clients. But these sort of tests, where you only interact with the browser output, has some disadvantages.

Imagine you want to create an article and check that this node is unpublished by default. How do you check this? Remember you only have the browser output…

One possible way could be this: Login, visit the Article creation form, fill the fields, click submit, and then… Maybe search for some unpublished class in the html:

var assert = require('assert'); describe('create article', function() { it('should be possible to create articles, unpublished by default', function() { browser.loginAs('some user'); browser.url('http://example.com/node/add/article') browser.setValueSafe('#edit-title-0-value', 'My new article'); browser.setWysiwygValue('edit-body-0-value', 'My new article body text'); browser.click('#edit-submit'); browser.waitForVisible('.node-unpublished'); }); });

This is quite simple to understand, but it has some drawbacks.

For one, it depends on the theme to get the status of the node. You could take another approach and instead of looking for a .node-unpublished class, you could logout from the current session and then try to visit the url to look for an access denied legend.

Getting Low-Level Information from a Browser Test

So the problem boils down to this:

How can I get information about internal properties from a browser test?

The new age of decoupled Drupal brings an answer to this question. It could be a bit counterintuitive at first, therefore just try to see is fit for your project.

The idea is to use the new modules that expose Drupal internals, through json endpoints, and use javascript together with a high-level testing framework to get the info you need.

In Gizra we use WDIO tests write end-to-end tests. We have some articles about this topic. We also wrote about a new module called JsonAPI that exposes all the information you need to enrich your tests.

The previous test could be rewritten into a different test. By making use of the JsonAPI module, you can get the status of a specific node by parsing a JSON document:

var assert = require('assert'); describe('create article', function() { it('should be possible to create articles, unpublished by default', function() { browser.loginAs('some user'); browser.url('http://example.com/node/add/article') browser.setValueSafe('#edit-title-0-value', 'My unique title'); browser.setWysiwygValue('edit-body-0-value', 'My new article body text'); browser.click('#edit-submit'); // Use JSON api to get the internal data of a node. let query = '/jsonapi/node/article' += '?fields[node--article]=status' += '&filter[status]=0' += '&filter[node-title][condition][path]=title' += '&filter[node-title][condition][value]=My unique title' += '&filter[node-title][condition][operator]=CONTAINS' browser.url(query); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); assert.ok(json[0].id); assert.equals(false, json[0].attributes.content['status']); }); });

In case you skipped the code, don’t worry, it’s quite simple to understand, let’s analyze it:

1. Create the node as usual:

This is the same as before:

browser.url('http://example.com/node/add/article') browser.setValueSafe('#edit-title-0-value', 'My unique title'); browser.setWysiwygValue('edit-body-0-value', 'My new article body text'); browser.click('#edit-submit'); 2. Ask JsonAPI for the status of an article with a specific title:

Here you see the two parts of the request and the parsing of the data.

let query = '/jsonapi/node/article' += '?fields[node--article]=status' += '&filter[status]=0' += '&filter[node-title][condition][path]=title' += '&filter[node-title][condition][value]=My unique title' += '&filter[node-title][condition][operator]=CONTAINS' browser.url(query); 3. Make assertions based on the data:

Since JsonAPI exposes, well, json data, you can convert the json into a javascript object and then use the dot notation to access to a specific level.

This is how you can identify a section of a json document. browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); assert.ok(json[0].id); assert.equals(false, json[0].attributes.content['status']); A Few Enhancements

As you can see, you can parse the output of a json request directly from the browser.

browser.url('/jsonapi/node/article'); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false));

The json object now contains the entire response from JsonAPI that you can use as part of your test.

There are some drawbacks of the previous approach. First, this only works for Chrome. That includes the Json response inside a XML document. This is the reason why you need to get the HTML from body pre.

The other problem is this somewhat cryptic section:

let query = '/jsonapi/node/article' += '?fields[node--article]=status' += '&filter[status]=0' += '&filter[node-title][condition][path]=title' += '&filter[node-title][condition][value]=My unique title' += '&filter[node-title][condition][operator]=CONTAINS'

The first problem can be fixed using a conditional to check which type of browser are you using to run the tests.

The second problem can be addressed using the d8-jsonapi-querystring package, that allows you to write an object that is automatically converted into a query string.

Other Use Cases

So far, we used JsonAPI to get information about a node. But there are other things that you can get from this API. Since all configurations are exposed, you could check if some role have some specific permission. To make tests shorter we skipped the describe and it sections.

browser.loginAs('some user'); let query = '/jsonapi/user_role/user_role' += '?filter[is_admin]=null' browser.url(query); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); json.forEach(function(role) { assert.ok(role.attributes.permissions.indexOf("bypass node access") == -1); });

Or if a field is available in some content type, but it is hidden to the end user:

browser.loginAs('some user'); let query = '/jsonapi/entity_form_display/entity_form_display?filter[bundle]=article' browser.url(query); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); assert.ok(json[0].attributes.hidden.field_country);

Or if some specific HTML tag is allowed in an input format:

let query = '/jsonapi/filter_format/filter_format?filter[format]=filtered_html' browser.url(query); browser.waitForVisible('body pre'); let json = JSON.parse(browser.getHTML('body pre', false)); let tag = '<drupal-entity data-*>'; assert.ok(json[0].attributes.filters.filter_html.settings.allowed_html.indexOf(tag) > -1);

As you can see, there are several use cases. The benefits of being able to explore the API by just clicking the different links sometimes make this much easier to write than a kernel test.

Just remember that this type of tests are a bit slower to run, since they require a full Drupal instance running. But if you have some continuous integration in place, it could be an interesting approach to try. At least for some specific tests.

We have found this quite useful, for example, to check that a node can be referenced by another in a reference field. To check this, you need the node ids of all the nodes created by the tests.

A tweet by @skyredwang could be accurate to close this post.

Remember how cool Views have been since Drupal 4.6? #JSONAPI module by @e0ipso is the new "Views".

— Jingsheng Wang (@skyredwang) January 9, 2018

Continue reading…

Categories: Drupal

Video Game Deep Cuts: Inside The RNG Tetris Effect

Social/Online Games - Gamasutra - 1 July 2018 - 7:37pm

This week's highlights include a piece on random number generation in classic games, what the upcoming Tetris Effect can learn from other classic updates, & lots more. ...

Categories: Game Theory & Design

FZ Test

New Drupal Modules - 1 July 2018 - 2:05pm
Origin

A wanted to make a little module to help the Drupal development

Features

There are functions:
fz_t(variable name) - to write out the value of variable (array also)

fz_die() - The same than fz_t() + die();
fz_mem() - shows only the memory using
fz_q() - wuery testing

Categories: Drupal

FZ Teszt

New Drupal Modules - 1 July 2018 - 1:59pm
Origin

A wanted to make a little module to help the Drupal development

Features

There are functions:
fz_t(variable name) - to write out the value of variable (array also)

fz_die() - The same than fz_t() + die();
fz_mem() - shows only the memory using
fz_q() - wuery testing

Categories: Drupal

An object at rest

Adventures in Interactive FIction - 17 May 2008 - 2:03pm

So obviously, the pendulum of progress stopped swinging on my game.  As much as I tried to prevent it, pressing obligations just wouldn’t take a back seat (nor would the burglars who, a few weeks ago, stole 90% of my wardrobe and who last week stole my monitor).  So after a string of hectic weekends and even crazier weeks, this weekend has been pretty wide open for doing whatever I want to do.  And not a moment too soon!

So after doing all the other things I try to do with my weekends, I finally loaded up the ol’ Inform 7 IDE and started working on my game.  To get me back in the swing of things, so to speak, I started reading through what I’d already written.  It was an interesting experience.

Strangely, what impressed me most was stuff I had done that I have since forgotten I learned how to do.  Silly little things, like actions I defined that actually worked, that had I tried to write them today, probably would have had me stumped for a while.  Go me!  Except, erm, I seem to have forgotten more than I’ve retained.

I also realized the importance of commenting my own code.  For instance, there’s this snippet:

A thing can be attached or unattached. A thing is usually unattached. A thing that is a part of something is attached.

The problem is, I have no idea why I put it in there – it doesn’t seem relevant to anything already in the game, so I can only imagine that I had some stroke of genius that told me I was going to need it “shortly” (I probably figured I’d be writing the code the next night).  So now, there’s that lonely little line, just waiting for its purpose.  I’m sure I’ll come across it some day; for now, I’ve stuck in a comment to remind myself to stick in a comment when I do remember.

It reminds me of all the writing I did when I was younger.  I was just bursting with creativity when I was a kid, constantly writing the first few pages of what I was sure was going to be a killer story.  And then I’d misplace the notebook or get sidetracked by something else, or do any of the million other things that my easily distracted self tends to do.  Some time later, I’d come across the notebook, read the stuff I’d written and think, “Wow, this is great stuff!  Now… where was I going with it?”  And I’d never remember, or I’d remember and re-forget.  Either way, in my mother’s attic there are piles and piles of notebooks with half-formed thoughts that teem with potential never to be fulfilled.

This situation – that of wanting to resume progress but fumbling to pick up the threads of where I left off –  has me scouring my memory for a term I read in Jack London’s Call of the Wild.  There was a part in the book where Buck’s owner (it’s late, his name has escaped me) has been challenged to some sort of competition to see if Buck can get the sled moving from a dead stop.  I seem to remember that the runners were frozen to the ground.  I thought the term was “fast break” or “break fast” or something to that effect, but diligent (does 45 seconds count as diligent?) searching has not confirmed this or provided me with the right term.  Anyway, that’s how it feels tonight – I feel as if I’m trying to heave a frozen sled free from its moorings.

The upside is, I am still pleased with what I have so far.  That’s good because it means I’m very likely to continue, rather than scrap it altogether and pretend that I’ll come up with a new idea tomorrow.  In the meantime, I’ll be looking for some SnoMelt and a trusty St. Bernard to get things moving again.

Categories:

Time enough (to write) at last…

Adventures in Interactive FIction - 14 April 2008 - 3:24pm

So I didn’t get as much coding done over the weekend as I had hoped, mainly because the telephone company *finally* installed my DSL line, which meant I was up til 5:30 Saturday am catching up on the new episodes of Lost.  That, in turn, meant that most of the weekend was spent wishing I hadn’t stayed up until such an ungodly hour, and concentration just wasn’t in the cards.

However, I did get some stuff done, which is good.  Even the tiniest bit of progress counts as momentum, which is crucial for me.  If the pendulum stops swinging, it will be very hard for me to get it moving again.

So the other day, as I was going over the blog (which really is as much a tool for me as it is a way for me to share my thoughts with others), I realized I had overlooked a very basic thing when coding the whole “automatically return the frog to the fuschia” bit…

As the code stood, if the player managed to carry the frog to another room before searching it, the frog would get magically returned to the fuschia.  This was fairly simple to resolve, in the end – I just coded it so that the game moves (and reports) the frog back to fuschia before leaving the room.  I also decided to add in a different way of getting the key out of the frog – in essence, rewarding different approaches to the same problem with success.

Which brings me to the main thrust of today’s post.  I have such exacting standards for the games I play.  I love thorough implementation.  My favorite games are those that build me a cool gameworld and let me tinker and explore, poking at the shadows and pulling on the edges to see how well it holds up.  A sign of a good game is one that I will reopen not to actually play through again, but to just wander around the world, taking in my surroundings.  I’ve long lamented the fact that relatively few games make this a rewarding experience – even in the best games, even slight digging tends to turn up empty, unimplemented spots.

What I am coming to appreciate is just how much work is involved in the kind of implementation I look for.  Every time I pass through a room’s description, or add in scenery objects, I realize just how easy it is to find things to drill down into.  Where there’s a hanging plant, there’s a pot, dirt, leaves, stems, wires to hang from, hooks to hang on, etc.  Obviously, unless I had all the time in the world, I couldn’t implement each of these separately, so I take what I believe to be the accepted approach and have all of the refer to the same thing.  Which, in my opinion, is fine.  I don’t mind if a game has the same responses for the stems as it does for the plant as a whole, as long as it has some sort of relevant response.  Even so, this takes a lot of work.  It might be the obsessive part of me, but I can’t help but think “What else would a person think of when looking at a hanging plant?”

Or, as I’ve come to think of it:  WWBTD?

What Would Beta Testers Do?

I’ve taken to looking at a “fully” implemented room and wondering what a player might reasonably (and in some cases unreasonably) be expected to do.  This is a bit of a challenging process for me – I already know how my mind works, so trying to step outside of my viewpoint and see it from a blind eye is hard.   I should stop for a second to note that I fully intend to have my game beta tested once it reaches that point, but the fewer obvious things there are for testers to trip over, the more time and energy they’ll have for really digging in and trying to expose the weaknesses I can’t think of.

I’ve found one resource that is both entertaining and highly informative to me:  ClubFloyd transcripts.  ClubFloyd, for the uninitiated (a group among which I count myself, of course) is a sort of cooperative gaming experience — if anyone who knows better reads this and cares to correct what may well be a horrible description, by all means!– where people get together on the IFMud and play through an IF title.  The transcripts are both amusing and revealing.  I recently read the Lost Pig transcript and it was quite interesting.  The things people will attempt to do are both astonishing and eye-opening.  In the case of Lost Pig (which, fortunately, I had already played before reading the transcript), what was even more amazing was the depth of the game itself.  I mean, people were doing some crazy ass stuff – eating the pole, lighting pants on fire, and so on.  And it *worked*.  Not only did it work, it was reversible.  You obviously need the pole, so there’s a way to get it back if, in a fit of orc-like passion, you decide to shove it in down Grunk’s throat.

Anyway, my point is, the transcripts gave me a unique perspective on the things people will try, whether in an effort to actually play the game, to amuse themselves, or to amuse others.  Definitely good stuff to keep in mind when trying to decide, say, the different ways people will try to interact with my little porcelain frog.

Other Stuff I Accomplished

So I coded in an alternate way to deal with the frog that didn’t conflict with the “standard” approach.  I also implemented a few more scenery objects.  Over the course of the next few days, I’m going to try to at least finish the descriptions of the remaining rooms so that I can wander around a bit and start really getting to the meat of it all.  I also want to work on revising the intro text a bit.  In an effort to avoid the infodumps that I so passionately hate, I think I went a little too far and came away with something a bit too terse and uninformative.  But that’s the really fun part of all of this – writing and re-writing, polishing the prose and making it all come together.

Whattaya know.  Midnight again.  I think I’m picking up on a trend here.

Categories:

Day Nothing – *shakes fist at real life*

Adventures in Interactive FIction - 8 April 2008 - 12:13pm

Grrr… I’ve been so bogged down in work and client emergencies that progress on the game is at a temporary (no, really!  Only temporary) standstill.  I’ve managed to flesh out a few more room and scenery descriptions, but have not accomplished anything noteworthy in a few days.  Hopefully after this week most of the fires on the work front will be extinguished, and I’ll have time to dive into the game this weekend.

(She says to no one, since there’s been one hit on this blog since… it started.)

Categories:

Pages

Subscribe to As If Productions aggregator