Behavior, Content, Money – 3 Things you should never give away for free!!!

BCmoney MobileTV

Integrate PHP based SOAP RPS game server in another language, JAVA desktop GUI

Posted by bcmoney on February 23, 2017 in Gaming, Java, PHP, Web Services with No Comments


No Gravatar
Rock-paper-scissors chart

Rock-paper-scissors chart (Photo credit: Wikipedia)

Now that we have a Web Service ready to consume (even though it is SOAP based), it should be pretty easy to extend to Java, which also means it should be possible with a little bit of effort to create a Desktop GUI.

For more on creating a Java-based SOAP server to have an all-Java version of this solution, see:
https://netbeans.org/kb/docs/websvc/jax-ws.html

 

 

See the other parts here:

Exposing your PHP Rock Paper Scissors game via SOAP Web Services

Posted by bcmoney on January 14, 2017 in Gaming, PHP, Web Services with No Comments


No Gravatar

Rock-paper-scissors chart

Rock-paper-scissors chart (Photo credit: Wikipedia)


So why SOAP? Well quite simply this was what I used back when I was first working through PHP and learning the hard way how to expose some server-side “business logic” as a Web Service. This was over a decade ago (late 2006 through 2007), and Google’s SOAP Search API had yet to be phased out, and was still one of the biggest reference implementations of SOA. In all truth I’d almost never use SOAP for creating Web Services from scratch anymore, but it does have a few minor advantages in niche cases thanks to ws-security, SAML integration, well-formed response guarantee via schema validation, contract-first development for more stability amongst separate inter-dependent departments/organizations, etc.

It also serves as a useful tool to go back and review every now and then, especially if your consulting ever takes you to an enterprise gig that still uses legacy SOA technologies (and yes despite REST taking over 6 years ago followed shortly by JSON replacing XML, there are still a decent amount of SOAP-based WS deployments out there at big companies, the kind of big enterprises with big budgets at stake and/or political reasons to keep their legacy technology stacks running). REST/JSON may have won the internet thanks to its simplicity, but there’s something to be said about what the various organizations that came up with SOAP and the ws-* stack had in mind (aside from complexity and lucrative implementation contracts/tooling sales), namely robustness and predictability. Take Netflix and YouTube for example, two of the most frequently called APIs on the web, both “RESTful-ish” but each taking their own liberties with Fielding’s original REST thesis in unique ways, particularly around Auth mechanisms and Usage Policies required to work with the data, DRM, Advertising, somewhat creative usage-restricting API metering, and/or pay-per-use schemes that come into play as soon as you want to do anything serious with the data, and both have suffered their developer communities significant amounts of non-backwards-compatible disruptive versioning, changes and feature deprecation.

Endpoint
http://bcmoney-mobiletv.com/widgets/games/rps/soap

Web Service Description Language (WSDL)
This is the “contract” part of SOAP that tells SOAP clients how to interact with our Web Service. In general, you can reach the WSDL of a SOAP-based Web Service:
http://bcmoney-mobiletv.com/widgets/games/rps/soap?wsdl

A useful tool for validating your WSDL is the W3C WSDL Validator service.

XML Schema (XSD)
I’m a big fan of keeping the same basic format between requests and responses rather than many Web Services out there with vastly different request and response formats. This just creates unnecessary work writing (or annotating/generating) distinct XML parsers.

Request format:

 <rps>
  <game id="1234">
    <player id="1234#p1">
      <choice>PAPER</choice>
    </player>
    <player id="1234#p2">
      <choice="SCISSORS</choice>
    </player>
   </game>
 </rps>

Response format:

<rps>
  <game id="1234">
    <player id="1234#p1" outcome="WON">
      <wins>5</wins>
      <losses>4</losses>
      <draws>2</draws>
    </player>
    <player id="1234#p2" outcome="LOST">
      <wins>4</wins>
      <losses>5</losses>
      <draws>2</draws>
    </player>
   </game>
 </rps>

Notice how only the data underneath the player element changes between request and response, and the two formats are virtually identical.

For more easily visualizing WSDL’s available operations and the data formats within each operation’s response check out the XML Grid – XSD/WSDL Viewer service.

Check some of the classic SOAP API examples that are still around today including Amazon’s Product Adveristing API (WSDL) which I’ve previously used as a product data source in my XmasListz Facebook App or the WebServiceX Currency Exchange API (WSDL) which was used in my post on how to work with SOAP in JavaScript & jQuery.

See the other parts here:

Moving a command-line PHP Rock Paper Scissors game to the Browser

Posted by bcmoney on December 1, 2016 in Gaming, PHP with No Comments


No Gravatar
Rock-paper-scissors chart

Rock-paper-scissors chart (Photo credit: Wikipedia)

In the first part we saw an example for creating a PHP Rock Paper Scissors game that waits for user input via the command-line and then evaluates the output of the game. Next we see an example for porting our basic command-line PHP Rock Paper Scissors game to the browser to reach a broader audience, since well, not that many people play command-line games these days.


Benefits of the Browser

With a Browser we have a few more useful tools at our disposal, as we can start to keep track of games played (wins/losses) over the lifetime of a particular user session. We also have the potential to open up the game to multiplayer more easily, as a player could play against others if we added a login mechanism (while a proper multi-user session persistence and secure login/logout mechanism is outside the scope of this example, a simple demo will be presented for enabling “play against a friend” mode with unique Game IDs).


Sessions

Sessions in PHP combine the use of short-term server-side persistence which lasts the lifetime of the page our code sits on, in combination with Cookies to extend that lifetime beyond an accidental page reload or tab close so that a session can be resumed. When you use a Session you’ll get a session ID of the name:

PHPSESSID

With a long unique alphanumeric identifier, such as:

49cdf231ddf8502e307c437ef98fd632

The Cookie representing this name/value pair looks roughly as follows (as viewed in the CookieManager+ plugin for FireFox):
In raw text that Cookie would look simply like this:

PHPSESSID=hfdvcdrj8hr6p6blkg9tt00av6; path=/; domain=gtk.php.net

And the value will be passed with each request from the client to the server along with the regular HTTP Headers (User-Agent, etc), in order to identify our device/browser/OS combination. It looks like this:

Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection keep-alive
Cookie PHPSESSID=hfdvcdrj8hr6p6blkg9tt00av6; LAST_LANG=en; COUNTRY=NA%2C156.34.241.222
Host gtk.php.net
Upgrade-Insecure-Requests 1
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0


Multiplayer

Multiplayer in the traditional sense would require a scalable, dedicated server for connecting large pools of users or a sophisticated P2P routing algorithm. Ideally, these days, a P2P networking solution would be used to enable direct communication between the parties playing a game together.

 

Read the rest of this entry »

Creating a basic Rock Paper Scissors game in PHP

Posted by bcmoney on November 9, 2016 in E-Learning, Gaming, PHP with 1 Comment


No Gravatar
Rock-paper-scissors chart

Rock-paper-scissors chart (Photo credit: Wikipedia)

This tutorial will outline the creation of a very basic game I created a long time ago in PHP for the purpose of learning some basic concepts around inputs/outputs from the command-line, decision trees (nested “if-elseif-else” type statements) and variability in PHP’s presentation layer. I thought I’d dust this one off in particular to emphasize how easy it is to create a basic game and encourage readers to tinker with their own simple game creation.

This is the first part of a four part series. The first part is reading from the command-line if the program is run from a console/terminal (and how to determine this). The next part will show how to convert the same program to work via a browser as well if run from there (and how to detect this). The third part shows how you can extend the game to allow different formats for displaying it (depending on where it was being integrated) via SOAP Web Services. The fourth part shows how to create a basic Java-based desktop application that consumes the SOAP Web Service. Yes you heard right, SOAP not REST, because I created this example over a decade ago just before AJAX, REST and later JSON started taking the development world by storm.

These experiments would shine an important light on the diverse capabilities of PHP for me in my early days of learning the language, some 11-12 years ago, and also demonstrated some of its limitations (i.e. did not realize at the outset that PHP had no GUI system on its own like Java’s AWT or Swing, and that without somewhat obscure 3rd-party C-based frameworks like GTK+, Qt-php, wxWidgets, etc your only choice for interaction is command-line, browser or exposing an API that can be consumed by another programming language).

Inputs
You will be given the selection of any of the following values:

  • Rock (also accept “R” or the representative number “0” which looks kinda like a rock)
  • Paper (also accept “P” or the representative number “1” which kind of looks like a flat piece of paper)
  • Scissors (also accept “S” or the representative number “2” which might require a bit more imagination, but just use your fingers to say “2” and it seems like a good fit as well)

This can be presented to the player and read in to the game via a variety of possible entry methods (i.e. toggling a Radio box, selecting from a single-value dropdown, typing in command-line, or in our case, clicking on an image).

Read the rest of this entry »

E-Commerce Shopping Cart in JavaScript and PHP

Posted by bcmoney on May 18, 2015 in E-Commerce, JavaScript, PHP with No Comments


No Gravatar
English: Jewel-Osco - monster shopping cart truck

English: Jewel-Osco – monster shopping cart truck (Photo credit: Wikipedia)

In E-Commerce, a “frictionless experience” is often described as the ultimate design goal when it comes to the consumer’s purchasing experience. An easy-to-use, robust shopping cart solution that can easily have any number of diverse types of items added to it, calculate shipping & handling, taxes and any other additional fees (where such apply), provides transparency and immediacy to the customer’s purchase decision. Doing this well can mean the difference between huge sales numbers and lackluster or disappointing sales figures.

Boiling all the Shopping Cart solutions out there to the most common, key functions we should expect a solution to support are:

  • Add/Remove items
  • Tabulate itemized sub-total
  • Calculate shipping & handling
  • Calculate taxes & fees
  • Tabulate total
  • Remember History for later purchase completion
  • Purchase/Checkout confirmation process

Other nice-to-have features that begin to move away from basic “Cart” functionality and into holistic E-Commerce platforms, include:

  • Multi-Address memory (billing, shipping… home, work, summer, etc)
  • Multi-Currency support (switch currency at any time)
  • Multi-Lingual support (switch languages at any time, i18n)
  • Multi-Layout support (switch look & feel at any time, l10n)
  • Storefront & “canned store templates”
  • Layout drag&drop/point-click customization (as per SquareSpace, Wix, etc)
  • Auto-fill forms (with customers’ stored Address info)
  • Auto-billing (subscriptions/recurring payments)
  • Notification options for receipt (Email, SMS, Phone notification, etc… in addition to on-screen)
  • International Shipment Tracking (parcel status check)
  • Returns processing
  • 3rd party payment support options (CreditCard, Interac eTransfer via Moneris/PaySafe, PayPal, 2checkout, etc)
  • PCI & PA-DSS compliance (possibly by payment gateway deferral for sensitive data)
  • Item import/export
  • Ratings (star, thumbs up/down, etc)
  • Reviews (public or private textual customer feedback)
  • Search
  • Wish List curation
  • Product/Service Recommendations
  • Discounts (coupons, limited-time offers, affiliate codes, etc)
  • Promotions (buy X get Y, welcome emails, inactive account enticements, etc)
  • Loyalty Program (points, rewards, etc)
  • Tracking company/brand affinity & engagement
  • Inventory Management (real-time RFID, NFC, etc)
  • Supply-Chain Management (SCM)
  • Customer Relationship Management (CRM)
  • Advertising platform integration
  • Analytics platform integration
  • Social Media platform integration

There are tons more possible features but those two lists capture the main ones. Having defined a Shopping Cart and our expectations of its basic capabilities, the remainder of this post will summarize how to roll your own super simple yet intuitive E-Commerce Shopping Cart in JavaScript and PHP that gets out of the customer’s way as much as possible, focusing on the first key set of options only; it will also include thoughts on how the base functionality could easily be expanded out to include some or all of the nice-to-haves of a full-fledged E-Commerce platform.
Read the rest of this entry »

BC$ = Behavior, Content, Money

The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:

1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.

2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.

3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.

  • Archives