Newsfeeds

Activity simulator could eventually teach robots tasks like making coffee or setting the table

Virtual Reality - Science Daily - 30 May 2018 - 8:31am
Recently, computer scientists have been working on teaching machines to do a wider range of tasks around the house. Researchers demonstrate 'VirtualHome,' a system that can simulate detailed household tasks and then have artificial 'agents' execute them, opening up the possibility of one day teaching robots to do such tasks.
Categories: Virtual Reality

Lullabot: Decoupled Drupal Hard Problems: Routing

Planet Drupal - 30 May 2018 - 8:00am

As part of the Decoupled Hard Problems series, in this fourth article, I'll discuss some of the challenges surrounding routing, custom paths and URL aliases in decoupled projects. 

Decoupled Routing

It's a Wednesday afternoon, and I'm using the time that Lullabot gives me for professional development to contribute to Contenta CMS. Someone asks me a question about routing for a React application with a decoupled Drupal back-end, so I decide to share it with the rest of the Contenta Slack community and a lengthy conversation ensues. I realize the many tendrils that begin when we separate our routes and paths from a more traditional Drupal setup, especially if we need to think about routing across multiple different consumers. 

It's tempting to think about decoupled Drupal as a back-end plus a JS front-end application. In other words, a website. That is a common use case, probably the most common. Indeed, if we can restrict our decoupled architecture to a single consumer, we can move as many features as we want to the server side. Fantastic, now the editors who use the CMS have many routing tools at their disposal. They can, for instance, configure the URL alias for a given node. URL aliases allow content editors to specify the route of a web page that displays a piece of content. As Drupal developers, we tend to make no distinction between such pieces of content and the web page that Drupal automatically generates for it. That's because Drupal hides the complexity involved in making reasonable assumptions:

  •  It assumes that we need a web page for each node. Each of those has a route node/<nid> and they can have a custom route (aka URL alias).
  •  It means that it is okay to add presentation information in the content model. This makes it easy to tell the Twig template how to display the content (like field_position = 'top-left') in order to render it as the editor intended.

Unfortunately, when we are building a decoupled back-end, we cannot assume that our pieces of content will be displayed on a web page, even if our initial project is a website. That is because when we eventually need a second consumer, we will need to make amends all over the project to undo those assumptions before adding the new consumer.

Understand the hidden costs of decoupling in full. If those costs are acceptable—because we will take advantage of other aspects of decoupling—then a rigorous separation of concerns that assigns all the presentation logic to the front-end will pay off. It takes more time to implement, but it will be worth it when the time comes to add new consumers. While it may save time to use the server side to deal with routing on the assumption that our consumer will be a single website,  as soon as a new consumer gets added those savings turn into losses. And, after all, if there is only a website, we should strongly consider a monolithic Drupal site.

undefined

After working with Drupal or other modern CMSes, it's easy to assume that content editors can just input what they need for SEO purposes and all the front-ends will follow. But let's take a step back to think about routes:

  • Routes are critical only for website clients. Native applications can also benefit from them, but they can function with just the resource IDs on the API.
  • Routes are important for deep linking in web and native applications. When we use a web search engine in our phone and click a link, we expect the native app to open on that particular content if we have it installed. That is done by mapping the web URL to the app link.
  • Links are a great way to share content. We want users to share links, and then let the appropriate app on the recipient's mobile device open if they have it installed.

It seems clear that even non-browser-centric applications care about the routes of our consumers. Luckily, Drupal considers the URL alias to be part of the content, so it's available to the consumers. But our consumers' routing needs may vary significantly.

Routing From a Web Consumer

Let's imagine that a request to http://cms.contentacms.io/recipes/4-hour-lamb-stew hits our React application. The routing component will know that it needs to use the recipes resource and find the node that has a URL alias of /4-hour-lamb-stew. Contenta can handle this request with JSON API and Fieldable Path—both part of the distribution. With the response to that query, the React app builds all the components and displays the results to the user.

It is important to note the two implicit assumptions in this scenario. The first is that the inbound URL can be tokenized to extract the resource to query. In our case, the URL tells us that we want to query the /api/recipes resource to find a single item that has a particular URL alias. We know that because the URL in the React side contains /recipes/... What happens if the SEO team decides that the content should be under https://cms.contentacms.io/4-hour-lamb-stew? How will React know that it needs to query the /api/recipes resource and not /api/articles?

The second assumption is that there is a web page that represents a node. When we have a decoupled architecture, we cannot guarantee a one-to-one mapping between nodes and pages. Though it's common to have the content model aligned with the routes, let's explore an example where that's not the case. Suppose we have a seasonal page in our food magazine for the summer season (accessible under /summer). It consists of two recipes, and an article, and a manually selected hero image. We can build that easily in our React application by querying and rendering the content. However, everything—except for the data in the nodes and images—lives in the react application. Where does the editor go to change the route for that page?

On top of that, SEO will want it so that when a URL alias changes (either editorially or in the front-end code) a redirect occurs, so people using the old URL can still access the content. Note that a change in the node title could trigger a change in the URL alias via Pathauto. That is a problem even in the "easy" situation. If the alias changes to https://cms.contentacms.io/recipes/four-hour-stewed-lamb, we need our React application to still respond to the old https://cms.contentacms.io/recipes/4-hour-lamb-stew. The old link may have been shared in social networks, linked to from other sites, etc. The problem is that there is no recipe with an alias of /recipes/4-hour-lamb-stew anymore, so the Fieldable Path solution will not cover all cases.

Possible Solutions

In monolithic Drupal, we'd solve the aforementioned SEO issue by using the Redirect module, which keeps track of old path aliases and can respond to them with a redirect to the new one. In decoupled Drupal, we can use that same module along with the new Decoupled Router module (created as part of the research for this article).

The Contenta CMS distribution already includes the Decoupled Router module for routing as we recommend this pattern for decoupled routing.

Pages—or visualizations—that comprise a disconnected selection of entities—our /summer page example—are hard to manage from the back-end. A possible solution could be to use JSON API to query the entities generated by Page Manager. Another possible solution would be to create a content type, with its corresponding resource, specific for that presentation in that particular consumer. Depending on how specific that content type is for the consumer, that will take us to the Back-end For Front-end pattern, which incurs other considerations and maintenance costs.

For the case where multiple consumers claim the same route but have that route resolve to different nodes, we can try the Contextual Aliases module.

The Decoupled Router

Decoupled Router is an endpoint that receives a front-end path and tries to resolve it to an entity. To do so it follows as many redirects and URL aliases as necessary. In the example of /recipes/four-hour-stewed-lamb it would follow the redirect down to /recipes/4-hour-lamb-stew and resolve that URL alias to node:1234. The endpoint provides some interesting information about the route and the underlying entity.

undefined

In a previous post, we discussed how multiple requests degrade performance significantly. With that in mind, making an extra request to resolve the redirects and aliases seems less attractive. We can solve this problem using the Subrequests module. Like we discussed in detail, we can use response tokens to combine several requests in one.

Imagine that we want to resolve /bread and display the title and image. However, we don’t know if /bread will resolve into an article or a recipe. We could use Subrequests to resolve the path and the JSON API entity in a single request.

undefined

In the request above, we provide the path we want to resolve. Then we get the following response.

undefined

To summarize, we can use Decoupled Router in combination with Subrequests to resolve multiple levels of redirects and URL aliases and get the JSON API data all in a single request. This solution is generic enough that it serves in almost all cases.

Conclusion

Routing in decoupled applications becomes challenging because of three factors:

  • Instead of one route, we have to think about (at least) two, one for the front-end and one for the back-end. We can mitigate this by keeping them both in sync.
  • Multiple consumers may decide different routing patterns. This can be mitigated by reaching an agreement among consumers. Another alternative is to use Contextual Aliases along with Consumers. When we want back-end changes that only affect a particular consumer, we can use the Consumers module to make that dependency explicit. See the Consumer Image Styles module—explained in a previous article—for an example of how to do this.
  • Some visualizations in some of the consumers don’t have a one-to-one correspondence with an entity in the data model. This is solved by introducing dedicated content types for those visualizations. That implies that we have access to both back-end and front-end. A custom resource based on Page Manager could work as well.

In general, whenever we need editorial control we'll have to turn to the back-end CMS. Unfortunately, the back-end affects all consumers, not just one. That may or may not be acceptable, depending on each project. We will need to make sure to consider this when thinking through paths and aliases on our next decoupled Drupal project.

Lucky for us, every project has constraints we can leverage. That is true even when working on the most challenging back-end of all—a public API that powers an unknown number of 3rd-party consumers. For the problem of routing, we can leverage these constraints to use the mitigations listed above.

Hopefully, this article will give you some solutions for your Decoupled Drupal Hard Problems.

Note: This article was originally published on November 29, 2017. Following DrupalCon Nashville, we are republishing (with updates) some of our key articles on decoupled or "headless" Drupal as the community as a whole continues to explore this approach further. Comments from the original will appear unmodified.

Photo by William Bout on Unsplash.

Categories: Drupal

ComputerMinds.co.uk: GDPR compliance steps for Drupal Developers

Planet Drupal - 30 May 2018 - 7:54am

The new GDPR laws are here, hurrah!

Having a number of developers handling databases from a number of client sites could easily be a nightmare, but we at ComputerMinds spent quite some time thinking about how to get and keep everybody safe and squeaky clean on the personal data front.

Here's a quick run-down of the key things to be aware of - and a pretty poster to help you keep it all in mind :)

Remove personal data from your system

  1. Review all databases on your computer, making sure to consider also those .sql dump files still sat in your downloads directory or your Recycle bin/trash.
  2. If there are databases that you need to keep on your system, then you must sanitize them by encrypting, anonymizing or removing personal data.
  3. Review all testing / UAT environments and ensure they're running off sanitized databases where possible.

Stay clean by using sanitized databases

Set up some _drush_sql_sync_sanitize() hooks to deal with personal data stored on your site. Then either have your Jenkins server use it to provide sanitized dumps, or ensure that your developers use it to sanitize databases immediately after importing.

When setting up your hook, make sure to consider things like:

  • User table - clear out email addresses, usernames etc.
  • Custom fields on users - names, telephone numbers etc. that you've added.
  • Webform / contact form submissions - make sure that your Webform / contact form data gets cleared out. Webform 7.12 and above has these hooks included, but it's good to double-check.
  • Commerce order table - you'll need to remove personal data from the commerce orders.
  • Commerce profile tables - make sure that the personal data in the profiles gets anonymized or removed.
  • Commerce payment gateway callback tables - these will have detailed payment transaction data, and absolutely must be cleared out.
  • URL aliases & redirects - by default Drupal sets up aliases for users' usernames, so you'll need to review those tables.
  • Comments - these usually have name, email and website fields that will need clearing out. But their body content may also have personal data in too, so you might be better off just binning the lot.
  • Watchdog / logging tables - these take up lots of space, so you probably don't want to export them off the live site anyway, but think seriously about the personal data inside if you do decide you want to import them elsewhere. Truncate recommended.
  • Cache tables - these can be huge, so you probably don't want to export them off the live site anyway, but think seriously about the personal data inside if you do decide you want to import them elsewhere. Truncate recommended.

This is certainly not a complete list, but we can't tell you what custom fun you've implemented on your site - so its' down to you to go check your tables!

Stay vigilant

  • Ensure future development environments and UAT/test environments are built using sanitized databases.
  • If you receive user data via email, immediately delete the email and attachments and reprimand the sender!
  • Talk to your clients about changes that need to be made to their sites.

PDF download link below!

 

Categories: Drupal

&amp;quot;Demetrios&amp;quot; Post Mortem – The lowest budget adventure game on all gaming platforms - by Fabrice Breton

Gamasutra.com Blogs - 30 May 2018 - 7:21am
How a random French programmer made a 10-hours adventure game by himself and his success to make a living out of it!
Categories: Game Theory & Design

Mobile App Growth Study: Why The Angry Birds Are So Popular - by Viral Patel

Gamasutra.com Blogs - 30 May 2018 - 7:20am
With Angry Birds, Rovio has produced some of the most impressive mobile growth statistics in the industry – $12 billion in revenue in 2012 and an estimated $50 billion in 2017. According to Rovio, their titles received over 3.7 billion downloads!
Categories: Game Theory & Design

The Global Games Market is About to Hit $138 Billion in 2018 - by Dr. Michael Garbade

Gamasutra.com Blogs - 30 May 2018 - 7:11am
The global gaming industry is projected to experience a remarkable growth in the coming years. Read this article to know about this exciting development.
Categories: Game Theory & Design

After login popup

New Drupal Modules - 30 May 2018 - 6:31am

Automatic login popup after the user logs in. The title and the body of the popup can be edited on the module's edit page.

Categories: Drupal

Dries Buytaert: Making the web easier and safer with the Web Authentication standard

Planet Drupal - 30 May 2018 - 6:05am

Firefox 60 was released a few weeks ago and now comes with support for the upcoming Web Authentication (WebAuthn) standard.

Other major web browsers weren't far behind. Yesterday, the release of Google Chrome 67 also included support for the Web Authentication standard.

I'm excited about it because it can make the web both easier and safer to use.

Supporting for the Web Authentication standard will make the web easier, because it is a big step towards eliminating passwords on the web. Instead of having to manage passwords, we'll be able to use web-based fingerprints, facial authentication, voice recognition, a smartphone, or hardware security keys like the YubiKey.

It will also make the web safer, because U2F will help reduce or even prevent phishing, man-in-the-middle attacks, and credential theft. If you are interested in learning more about the security benefits of the Web Authentication standard, I recommend reading Adam Langley's excellent analysis.

When I have a bit more time for side projects, I'd like to buy a YubiKey 4C to see how it fits in my daily workflow, in addition to what it would look like to add Web Authentication support to Drupal and https://dri.es.

Categories: Drupal

TEN7 Blog's Drupal Posts: Episode 029: Wilbur Ince, Drupal Frontend Developer and Human Rights Activist

Planet Drupal - 30 May 2018 - 5:54am
Wilbur Ince, Drupal Frontend Developer and Human Rights Activist, sits down with Ivan Stegic to discuss his career, road to Drupal and the valuable volunteer work he does.
Categories: Drupal

Jacob Rockowitz: Are we afraid to estimate our work in Drupal and open source?

Planet Drupal - 30 May 2018 - 5:54am

Estimation is not a new concept nor is it a bad word.

Estimation is not a new topic for anyone in the Drupal or open source community. We do it every day at our jobs. We even discuss estimation techniques at our conferences. We provide our clients with estimates when building and contributing back to open source project, yet we don't include estimations within our open source community and issue queues.

We all provide estimates to our clients - are we afraid to do it when it comes to Drupal and Open Source?

Before we take on this tough question, 'Are we afraid to estimate our work in Drupal and open source?', let's start off with a straightforward question: 'Why do we provide estimates to our clients?' The answer is just that our clients want to know how much something is going to cost and we want to know how much work is required to complete a project.

To give this discussion more context, let's begin with a very general definition of estimation

Here’s my hypothesis:

The Science of guessing - Drupal estimation techniques from project managers

While researching estimation within the Drupal community, I found a bunch of great presentations about project management and estimation. To me, "The Science of guessing - Drupal estimation techniques from project managers" by Shannon Vettes (svettes), Jakob Persson (solipsist), and Mattias Axelsson (acke), was the most comprehensive and inspiring presentation. Feel free to watch this presentation. I am going to pull a few slides from this presentation to help move through this exploration.

Every presentation I watched focused on estimation concerning managing expectations for...Read More

Categories: Drupal

How porting to the PSVita improved performance everywhere else. - by Lars Doucet

Gamasutra.com Blogs - 30 May 2018 - 1:00am
Porting our game to the Vita required lots of optimizations that helped all of our platforms. Read about what we did!
Categories: Game Theory & Design

Faceapi UI fix

New Drupal Modules - 29 May 2018 - 8:57pm

A tiny module that improves the breadcrumbs of Facetapi pages, especially with search_api_facetapi (part of Search API).
Requires Crumbs.

Example breadcrumb with this module enabled:
Home » Administration » Configuration » Search and metadata » Search API » Products index » Facets » Price » Filters

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