mankyKitty

(ns scrabble.core)

(def letter-scores [{:score 1 :letters "aeioulnrst"}
                    {:score 2 :letters "dg"}
                    {:score 3 :letters "bcmp"}
                    {:score 4 :letters "fhvwy"}
                    {:score 5 :letters "k"}
                    {:score 8 :letters "jx"}
                    {:score 10 :letters "qz"}])

mankyKitty

package scrabble;

public class Scrabble {
  private static final char[][] letters = new char[][] {
			{'a','e','i','o','u','l','n','r','s','t'}, 	// 1
			{'d','g'},  								// 2
			{'b','c','m','p'}, 							// 3
			{'f','h','v','w','y'}, 						// 4
			{'k'},  									// 5
			{'j','x'},  								// 8

mankyKitty

(ns bob.core
  (:require [clojure.string :as slib]
            [clojure.zip :as zlib]
            [clojure.java.io :as io])
  (:gen-class :main true))

(defn consonant-in? [s]
  (not (empty? (re-seq #"[^aeiouAEIOU\s]" (str s)))))

(defn leet-vowel [v]

mankyKitty

Exporting Views

This guide assumes you have a module ready to save the views but it does not have any Views integration or folder structure. Skip ahead if you've already created the folders and Views Hooks.

• Add the views folder to your module.
• Create a file called MODULENAME.views.inc inside the views folder.
• Add a default_views folder inside the views folder.

Your module directory structure should now resemble something like this:

mankyKitty

Using Views Data

As you're probably aware, if you want Views to acknowledge any of your fields, filters, sorts, or contextual filters; you have to declare their existence in the hook_views_data within your module. This is a brief guide into how to utilise this functionality.

This guide assumes you have already setup your Views integration using the API hook and you are ready to start declaring fields and other related items for your custom data. The basic structure of the array that is returned by the Views data hook is as follows:

    <Table Name>
    |-| <Field Name>

|--|

mankyKitty

#Views Handlers - A Shakedown

This is a cheat sheet for information about extending the capabilities of Views by extending and building your own handlers. It will cover the basic handlers and attempt to cover some of the hooks that you might use when doing so. Including examples, basic documentation and some caveats where necessary. THIS IS NOT A COMPLETE LIST!! Consider the code of the handler your looking to extend to be the ultimate source of documentation. This is merely a convenience and a starting point.

_Ignore the tags in the included snippets, they are a convenience for formatting.

Extending / Including Your Handler

• Determine which handler you're going to extend. (eg views_handler_field_numeric).
• Create a PHP .inc file using the class name of your handler: views_handler_field_my_numeric_field.inc.

mankyKitty

#Drupal & Apache Solr Integration

This is a cheat sheet and rough guide to the integration of Drupal and Apache Solr. It will contain useful functions and how to combine them, a basic layout on how the components fit together, and some DOs and DON'Ts. All of this is based on the apachesolr integration, if you're using a different module then this will probably be of no use to you.

Useful Functions

Load All Environments

Within the Apache Solr module there is support for connecting to multiple Solr instances, each the configured connections is considered an environment within the context of the Solr modules operations. When you're interacting with Solr and there is only one connection configured then you mostly do not have to be concerned with this as the module will load the default environment by itself. However you should always try to ensure that anything you construct around Solr is designed to handle the existence of multiple environments.

mankyKitty

Solr Query Syntax Basics

This is a super basic beginners guide to Solr Lucene query syntax. We're going to cover running a straightforward query, as well as some of the more useful functionality such as filtering and creating facets. We'll point out some things you can't do and generally give you enough instruction so that you can get yourself into trouble.

For testing you need a REST client capable of sending requests to your Solr instance. Either RESTClient for Firefox or Postman for Chrome are good choices.

Misc

Request Specific Fields

To specify a list of fields to return instead of the default Solr response use fl and provide a comma delimited list of fields:

mankyKitty

-module(test_str).

-compile(export_all).

strs() ->
  [" foo |# 3 3)", " foo #| bar |# foobar |# 3)"].

run_timing(Mod, Fun, [NoMatch|Match]) ->
  {MatchTime, _} = timer:tc(Mod, Fun, Match),
  {NoMatchTime, _} = timer:tc(Mod, Fun, NoMatch),

mankyKitty

(defmodule lfe_type_scan
  (export all))

(defun to-type-fun (t)
  "This function was taking the type atom 'atom and smooshing it into
\"atom()\" but this doesn't play well with how I've structured the fold
so I've left it for now whilst I tried other things."
  (list t)) ;; Until further notice

(defmacro with-spec args