Find out who will play and who is out in today’s injury report for the Los Angeles Lakers vs. Los Angeles Clippers game on November 1.

Lakers vs. Clippers Injury Report Today - November 1

Analyzing Wednesday’s Los Angeles Clippers at Los Angeles Lakers odds and lines, with NBA expert picks, predictions and best bets.

Los Angeles Clippers at Los Angeles Lakers odds, picks and predictions

Norman Powell and Bones Hyland's fantasy values were enhanced in the immediate aftermath of the James Harden trade, and they made the most of their opportunities on Tuesday.

Basketball Pickups: Powell, Hyland shine for shorthanded Clippers

E_Walker. LOB_Texas 51, Arizona 49. 2B_Jankowski, Jung, Carter 2, Seager, Lowe, Pham 3, Rivera, Walker 2, Marte 2, Thomas. 3B_Semien, Carroll. HR_García, Semien ...

Texas leads series 3-1

E_Walker (1). DP_Texas 1, Arizona 1. LOB_Texas 3, Arizona 6. 2B_Jung (1), Jankowski (1), Seager (1), Marte (2), Walker (2). 3B_Semien (1). HR_Seager (3), Semien (1 ...

Texas 11, Arizona 7

While Eastern Conference powerhouses Boston and Milwaukee made bold pickups in the summer, the 76ers instead learned that Harden desired a trade to the Clippers.

76ers trade disgruntled guard James Harden to Clippers, AP source says

Former NBA All-Star Kenyon Martin reacts to his son, KJ, being traded to the Philadelphia 76ers in the James Harden deal.

Former star Kenyon Martin reacts to son, KJ, being traded to Sixers

What if that Houston team, which went out in the bubble starting Harden and Westbrook next to Eric Gordon, Covington and Tucker, could have swapped two of its supporting characters for Kawhi Leonard and Paul George?

James Harden trade: Clippers give star guard everything he could ever ask for ... and one year to make it work

The trade we’ve been talking about since July but had dragged on so long that it became the boy who cried wolf of transactions has finally happened: James Harden is going to be a Los Angeles Clipper. On the surface everyone can save face with this trade ...

Winners, losers from blockbuster James Harden trade to Clippers

James Harden is finally going to the Clippers, ending a saga that began when Harden opted into the final year of his 76ers contract in late June. The deal was first reported by ESPN.

With James Harden trade, Clippers go for it and 76ers move on

Our company was started because two college kids had a problem: Our founder has said he’s in the business of giving developers superpowers because APIs can help you solve business problems faster, to both accelerate your career, but also to save time. The faster you automate your job, the more time you can spend doing what you love (like playing NBA Jam, which was pretty important to him at the time ;). they needed to send out physical mail, but they weren’t design or marketing experts, they were developers. Was there a way to do this programmatically? The solution: APIs. That was over 10 years ago, and while we’ve grown a lot, and our product offering has expanded, we still consider ourselves an API-first company offering direct mail automation, designed for developers. We are bringing physical mail into the digital age Direct mail continues to be an integral part of any outreach whether the goal is to inform, attract, retain, or win back customers (or heck, send out holiday cards). 👩‍💻  We provide easy-to-use APIs to automate sending letters, checks, and postcards—creating a personalized mail piece is as easy as creating an email or webpage 📫  We improve address integrity with autocomplete and address verification APIs 🖨  We have a nationwide network of on-demand printers 🔍  We track every single mail piece from creation to delivery We provide APIs that integrate with your favorite programming languages, user-friendly templates, and other digital tools. If “Elixir” sounds like something only Alice would drink, we also have a simple UI to enable almost anyone – technical or not – to create postcards, letters, checks, and more (whether it’s 1 or 1 million). Our network of printers gets your mailpieces printed and in the mail, and we’ll provide visibility along the way. You’ll know exactly what’s working, and what isn’t. That’s why we say we say direct mail: it’s connected, personalized, and measurable. intelligent You mean snail mail? Yup! But our automation transforms legacy manual processes; what used to take months, can now occur in a week. Bringing sexy (direct mail) back It’s not unusual to receive a hundred emails in a single day; email is the new junk mail. But 72% of consumers read direct mail immediately or on the same day they bring it inside their residence ( ), and direct mail has 13x higher response rate than email ( ). source source The tide is shifting and you don’t have to have a full-scale marketing department or direct mail SME on staff to ride the wave. Learn more Engineers, check out & our www.lob.com/Developers API docs Marketers, learn more about automating your direct mail campaigns here Direct Mail Operators, learn more here

Meet Lob

We got a lot of eyeballs on our article last fall about autocomplete and address verify with React. Since Lob recently migrated some of our front-end projects from Angular to Vue, we wanted to present a similar We’ll be creating a Vue app that demos both a single-line address field and an address form. solution for Vue developers to clean up both domestic and international addresses with component. Lob’s Vue Address Autocomplete Let’s get started! Getting Started We’ll use to quickly set up a Vue app and install @lob/vue-address-autocomplete: Vite npm create vite@latest
# Follow the prompts given by vite
cd my-demo-app
npm install @lob/vue-address-autocomplete
npm run dev After that last command visit to see your demo app in action. http://localhost:3000/ We’ll need a Lob API key in order to use Vue Address Autocomplete. Create an account at (it’s free) then follow to obtain your API key. For our demo app I recommend using your test public key to avoid any charges to your account and prevent any malicious activity. (These keys start with test_pub_xxxxxxxx) lob.com these instructions Address verification is disabled for test API keys. When we are ready to verify an address we’ll switch to our . NOTE: live public key Adding Autocomplete Replace the contents of the App.vue file generated by vite with the following code: <script setup>
import AddressAutocomplete from '@lob/vue-address-autocomplete'
import '@lob/vue-address-autocomplete/dist/styles.css'
</script>

<template>
  <main>
    <AddressAutocomplete
      apiKey="YOUR_API_KEY_HERE"
    />
  </main>
</template> In addition to importing AddressAutocomplete , you must also import the stylesheet that it uses (line 3). This could be done in your root component file or in only the file using AddressAutocomplete. Voilà! Our app now suggests addresses as input is entered. …But what if we want to autocomplete international addresses? International Autocomplete International autocomplete and verification work the same as the U.S. version with the addition of a couple props - isInternationaland country. Here’s what that looks like (only a couple of countries being used for simplicity): <script setup>
import AddressAutocomplete from '@lob/vue-address-autocomplete'
import '@lob/vue-address-autocomplete/dist/styles.css'
</script>

<template>
  <main>
    <label for="country" style="margin-right: 1em">Country</label>
    <select name="country" id="country" v-model="countryCode" style="margin-bottom: 1em">
      <option value="MX">Mexico</option>
      <option value="CA">Canada</option>
      <option value="FR">France</option>
      <option value="CN">China</option>
    </select>
    <AddressAutocomplete
      apiKey="YOUR_API_KEY_HERE"
      isInternational=true
      :country="countryCode"
    />
  </main>
</template>

<script>
  export default {
    data() {
      return {
        countryCode: ""
      }
    }
  }
</script> Although localities may vary by country (e.g. states, provinces, districts, etc.), the address suggestion objects for international addresses use the same keys as the U.S. with the addition of country. For example, Alberta is a province in Canada however Lob will respond with state: AB in its suggested addresses. This way your code doesn’t have to change when switching between domestic and international use cases. A couple of other things worth noting about international autocomplete: International autocomplete will not work for addresses from the U.S. or U.S. territories, please default back isInternational = false when autocompleting and verifying domestic addresses. countryCode must be a 2 letter country short-name code ( ). ISO 3166 Vue Address Autocomplete will call the Lob Address Verification (AV) API when the input has three or more characters. Let’s return to our initial U.S. autocomplete code for the remainder of this guide. Address Verification Lob’s address verification (AV) API checks the validity and deliverability of a physical mailing address in the U.S. or internationally. It also standardizes addresses, corrects typos, and provides analytics about the address being verified (e.g. coordinates, building type, type of delivery route, etc.). Just like with our react address autocomplete, our Vue component library includes the same verification function. <script setup>
import AddressAutocomplete, { verify } from '@lob/vue-address-autocomplete'
import '@lob/vue-address-autocomplete/dist/styles.css'
</script>

<template>
  <main>
    <AddressAutocomplete
      :apiKey="lobApiKey"
      @onInput="handleInput"
      @onSelect="handleSelect"
    />
    <button @click="handleSubmit">Verify</button>
    <p>
      {{verificationResult}}
    </p>
  </main>
</template>

<script>
export default {
  data() {
    return {
      address: '',
      lobApiKey: 'YOUR_LOB_API_KEY',
      verificationResult: null
    }
  },
  methods: {
    handleInput(userInput) {
      this.address = userInput
    },
    handleSelect(selectedAddress) {
      this.address = selectedAddress.value
    },
    handleSubmit() {
      verify(this.lobApiKey, this.address)
        .then((result) => {
          // Simplify response into something readable to the user
          const summary = `This address is ${result.deliverability}`
          this.verificationResult = summary
        })
        .catch((errorData) => this.verificationResult = errorData.message)
    }
  }
}
</script>

<style scoped>
  button {
    margin-top: 1em;
  }
</style> We’ve added address verification to our app by doing two things 1) by tracking the most recent autocomplete selection and 2) using verify to call Lob’s AV API and displaying the results. In this example, address can be both a suggested address object or the user’s input string. verify accepts both options which is useful in the event that a user verifies his/her address without selecting one of Lob’s suggestions. International address verification uses the function verifyInternational which requires an additional parameter countryCode. This is the same 2-letter country code passed into the AddressAutocomplete component for international. Displaying an Address Form At the moment there is no AddressForm component like there is in our React Address Autocomplete however building one is easy. Let’s extend our app to include multiple fields for each address component: <script setup>
import AddressAutocomplete, { verify } from '@lob/vue-address-autocomplete'
import '@lob/vue-address-autocomplete/dist/styles.css'
</script>

<template>
  <main>
    <div class="field">
      <label for='primary_line'>Address</label>
      <AddressAutocomplete
        :apiKey="lobApiKey"
        primaryLineOnly=true
        @onInput="handleInput"
        @onSelect="handleSelect"
        class="address-autocomplete"
      />
    </div>
    <div class="field">
      <label for='secondary_line'>Apt, Suite</label>
      <input id='secondary_line' v-model="address.secondary_line" />
    </div>
    <div class="field">
      <label for='city'>City</label>
      <input id='city' v-model="address.city" />
    </div>
    <div class="field">
      <label for='state'>State</label>
      <input id='state' v-model="address.state" />
    </div>
    <div class="field">
      <label for='zip_code'>Zip</label>
      <input id='zip_code' v-model="address.zip_code" />
    </div>

    <button @click="handleSubmit">Verify</button>
    <p>
      {{verificationResult}}
    </p>
  </main>
</template>

<script>
export default {
  data() {
    return {
      address: {
        primary_line: '',
        secondary_line: '',
        city: '',
        state: '',
        zip_code: '',
      },
      lobApiKey: 'YOUR_API_KEY_HERE',
      verificationResult: null
    }
  },
  methods: {
    handleInput(userInput) {
      this.address.primary_line = userInput
    },
    handleSelect(selectedAddress) {
      this.address = selectedAddress.value
    },
    handleSubmit() {
      verify(this.lobApiKey, this.address)
        .then((result) => {
          // Simplify response into something readable to the user
          const summary = `This primary_line is ${result.deliverability}`
          this.verificationResult = summary
        })
        .catch((errorData) => this.verificationResult = errorData.message)
    }
  }
}
</script>

<style scoped>
  .address-autocomplete {
    width: 100%
  }
  button {
    margin-top: 1em;
    align-self: flex-end;
  }
  .field {
    display: flex;
    flex-direction: row;
    justify-content: flex-end;
    margin: 0.5em 0em;
  }
  .field label {
    margin-right: 1em;
  }
  .field input {
    flex-grow: 1;
  }
</style> `address` becomes an object for each address component that are then bound to our new address fields. There is also a new prop passed to AddressAutocomplete called `primaryLineOnly,` when set to true the input’s value will only update to the suggested address’ primary_line instead of a complete single-line address. From there, the rest of our code operates the same. Styling AddressAutocomplete Simply override the classes used by AddressAutocomplete and/or the CSS variables it uses for a custom appearance. Here is a list of what can be customized: Style Variables
--lob-header-text-color
--lob-input-background-color
--lob-input-text-color
--lob-label-text-color
--lob-suggestion-item-active-background-color
--lob-suggestion-item-background-color
--lob-suggestion-item-text-color

Classes
lob-header
lob-label
lob-typeahead-root
lob-typeahead-input
lob-typeahead-input:focus-visible
lob-typeahead-input::placeholder
lob-typeahead-input-with-label
lob-typeahead-label
lob-typeahead-list
lob-typeahead-list-item
lob-typeahead-list-item-active Summary Address autocomplete and address verification has become a standard across many websites online. Vue fans can add this functionality to your web app easily and without giving up control of appearance or functionality. Plus Lob’s Address Verification product provides additional delivery data to enhance your app’s user experience such as coordinates, county, and delivery info. If you’d like to work with Lob’s Address Verification API directly check out the . API documentation here Additional resources @lob/vue-address-autocomplete repo Video tutorial available here Content courtesy of Lob Software Engineer Muhammad Martinez

How to add Address Autocomplete and Verification Using Lob’s Vue Component Library

Cómo agregar autocompletado de direcciones y verificación usando la biblioteca de componentes Vue de Lob

It’s Holiday Card season! But my hand hurts just thinking about addressing all those envelopes, and I can’t remember the last time I bought stamps…let’s be real, ain’t nobody got time for that. Fortunately, I happen to work for a company that sends direct mail programmatically. Many developers using one of our SDKs in their preferred programming language, but we recently launched our low-code and I thought I’d give it a whirl. integrate with Lob Campaigns ‍ The following is a step-by-step tutorial so you too can create personalized full-color 6”x9” holiday postcards—to be printed and mailed by Lob. For under a dollar each (inclusive of printing and postage) send season greetings to your loved ones. We’ll use the sample shown below, but those with more HTML knowledge can customize all they wish! Select and Prep Your Photos Choose two of your favorite photos: one landscape (for the front) and one portrait (for the back). Use your photo editing tool of choice to format each correctly; I used Preview on my Mac. To ensure they print at the highest quality they should be: 5x7 inches (1500 pixels x 2100 pixels in portrait and 2100 pixels x 1500 pixels in landscape), at a resolution of 300 pixels per inch, and saved in an RGB color profile. (If you are snagging photos from your iPhone, see the Appendix for a cheat sheet.) Label each clearly FRONT and BACK. ; I used a free account at . You will then need to host your images somewhere imgbb.com Prep Your Data 1. You will then need to snag the HTML for the and of the postcard (we’ll use it in a later step). front back 2. Next, you will prep your address data. and input your data: Make a copy of this spreadsheet Do not modify or add any column headers! Add the full name in the `name` column Add the address data (make sure that leading zeroes aren’t being dropped and that the state code is used) Replace the “Lorem ipsum” in the `message` column with your own personalized message. Make sure that the message fits within the space by being shorter than the placeholder examples (about 65 characters). You can test your holiday card messaging . HERE Add the links to your front and back images to every row in the `image_front` and `image_back` columns (links should look something like this: ) https://i.ibb.co/fpJ84Js/front.png 3. Download your address file . as a .csv Create Your HTML Templates Now, you are ready to create your postcards in the Lob dashboard. 1. First, you will need to . sign up for a free Lob account 2. Once you have registered, you will be taken to the dashboard. In the Developer tier, there is no cost to test out the Print & Mail APIs, but Payment information will need to be entered : Your name (top right) -> Settings -> Payment if you want to send live requests—and have a postcard printed and mailed—it will currently run you $0.896 a postcard (inclusive of printing and postage). here 3. Create & save HTML templates for the Front and Back of your postcard: On the left menu bar, Navigate to . HTML Templates Make sure Live is highlighted! Click on ‘Create’. Name this ‘Front Template’ and paste in the HTML code for the front. Click ‘Create’ to save. On the left menu, click HTML Templates to go back to the main template screen (You should see your new Front template there under Live templates.) Once again, ensuring Live is highlighted, click ‘Create’ again. Name this ‘Back Template’ and paste in the HTML code for the back. Click 'Create' to save. Click HTML templates to go back to the main template screen; you should see your new Back template there under Live templates. ** Make sure you see both templates are listed when Live is highlighted before proceeding.** Create and Send Your Postcards On the left menu bar, navigate to ; click on “Create Campaign” Campaigns Step 1: Configure Campaign 1. Enter a Name and Description 2. Campaign Type: Marketing 3. Mail Type: Postcard; Size: 6x9 4. Postage references: Return address is not required; Select postage: Up to you, ‍ note the listed expected delivery times 5. Cancellation Window: This is set at 5 minutes; you will not have the option to edit on the free Developer plan 6. Campaign-Level Metadata: Optional Step 2: Add Audience 1. Upload your CSV file (created during prep stages), or drag and drop it into the dashboard 2. Map required address variable: These are mapped automatically Step 3: Choose Creative 1. Under ‘Postcard Front’, select the HTML Template you created from the dropdown menu (note the previews will not show your images or messages as they are not mapped yet) 2. Under ‘Postcard Back’, select the HTML Template you created from the dropdown menu (note the previews will not show your images or messages as they are not mapped yet) 3. Connect your creative to your audience: Merge variable strictness: Ignore Connect/map your merge Variable from HTML to the appropriate column in the CSV: {{img_front}} to {{img_back}} to {{message}} to img_front, img_back, message Step 4: Review Campaign Review carefully, If something is not correct, click ‘Previous Step’ to edit. once you place your order, after 5 minutes, the live request will be sent to Lob; your postcards will be created and mailed, and you will be charged. If everything looks good, click ‘Place Order’ and your holiday cards will be on their way! You can view your postcards under Campaigns or Postcards (Live) in the Lob dashboard. Wrap up Lob was started by two developers who needed to solve a problem, and were the answer; the goal was to make sending mail just as easy as sending an email. direct mail APIs This is a fun personal use case, but Just like email, each mailpiece can be highly personalized, and automated. Lob is meant to automate direct mail—postcards, letters, checks, self-mailers, and more—at scale. For advanced tiers, Mail Analytics is available for each mailpiece to track each postcard along its journey to delivery (and if you included a QR code, you could even track the open rate). Appendix: How to Prep a Photo Not every developer is a designer, nor do they have commercial printing experience, so this part can be tricky. Email/Download a photo from your iPhone on your computer. The following steps are shown in the Preview app (Mac) but are a good guideline for any editing program. Select your back photo (portrait orientation). Under , select . Tools Adjust Size Change Resolution to . 300 pixels/inch For this photo (portrait orientation): Change the Width to 5 inches, and the Height will automatically change. Alternatively, update the Height to 7, and the Width will change. ; you will crop in the next step). It’s highly likely you won’t end up with a perfect 5x7; that’s ok: Change the field that results in one of the measurements being slightly too big Under , Drag the dotted line to pixels (as you move the line, the measurements will display; exaggerated below). Edit Select All. crop the image to the necessary 1500x2100 Under , select Generic RGB. (Photos must be saved in RGB.) Tools Assign Profile Make sure your photo is named clearly as the BACK. Save! Repeat these steps for the FRONT photo but in landscape orientation (7” wide x 5” high, 2100 pixels x 1500 pixels). ‍

How to Mail Your Holiday Cards Programmatically

As Staff Engineer on Lob’s team, I was recently tasked with standing up an endpoint for customers that supplied them with all the data we had stored for a particular zip code. We use pretty heavily to store our data so this boiled down to querying ES by zip code and writing the data to Amazon S3. But both services have subtle limitations on how you read/write them: ES caps your result set to 10,000 records, and Amazon S3 insists that you write to your buckets in chunks of at least 4 Megabytes. This turned out to be a perfect use case for Elixir streams! Address Verification Elasticsearch Elixir Streams Before we dive into the nitty gritty of Elasticsearch and AWS S3, let’s first do a brief refresher on Elixir Streams. What is a Stream? . This is typically accomplished by maintaining a little bit of state that describes where you currently are in your enumerable and a method of computing the next item. A trivial example would be a Stream of natural numbers: A Stream is a composable enumerable that is computed lazily Stream.iterate(0, fn x -> x + 1 end) The gory details of how this is implemented under the hood is the topic for another day. You rarely need to get that low level — the Stream library has a wealth of functions similar to that you can use as building blocks to construct your own Streams. And several Elixir library functions natively return streams: will turn a file (or other source) into a Stream allowing you to process very large files without having to read them into memory first in their entirety. The lazy aspect of Streams means that the minimum amount of the Stream is computed that’s needed to generate your answer. Enum IO.stream Imagine we want to find the 100th natural number that is palindromic and also divisible by 3: 1 
|> Stream.iterate(fn n -> n + 1 end) 
|> Stream.filter(fn n -> s = Integer.to_string(n); s == String.reverse(s) end)
|> Stream.filter(fn n -> rem(n, 3) == 0 end)
|> Enum.at(99) What I find elegant (and efficient) about this solution, is that no number beyond the answer, 20202, will be computed. Neat! If you’d like to dive in deeper, there’s a great Getting Started section on on the Elixir language website. The is also chock full of instructive examples. Enumerables and Streams Elixir API documentation Elasticsearch Now onto . The first thing to know is that After scrutinizing the documentation, it became clear that the original method that popped up on my Stack Overflow ( ) had been deprecated and the new approved method was to use . The process is: Elasticsearch ES caps the size of the result set at 10k items. Scroll API PointInTime IDs PIT IDs essentially give you a snapshot of your index at one point in time so that you get a consistent view of your search results across multiple queries. acquire a PIT for your index perform your queries using the PIT (without the index — it’s now implicit in the PID) delete the PIT That last step is crucial — PITs are extremely resource hungry so it is vital that you delete them as soon as you’re done. I borked our staging ES in my early experiments with PITs because I wasn’t deleting them and the expiration parameter seemed to have no effect. The other thing we’d like to do is abstract away the underlying PIT and paging mechanism for the end user so we provide an interface that just takes an ES query and generates a Stream of hits. Let’s start by creating and deleting the PID. is just a matter of requesting a PID associated with the index that we’re interested in running queries against. Creating the PID @spec create(ES.index_t()) :: {:ok, pit_t()} | {:error, ES.response_t()}
def create(index) do
  :post
  |> HTTP.request(url(index), HTTP.no_payload(), HTTP.json_encoding())
  |> HTTP.on_200(& &1["id"])
end is a simple HTTP delete except that the PIDs are huge so you need to supply them in the body and not as URL params. Some HTTP libraries won’t let you do this. The HTTP spec is a little muddy on the matter and last I checked on Stack Overflow there was a healthy debate on the subject. This is why we use HTTPoison — it allows payloads on DELETE requests. Deleting a PID @spec delete(pit_t()) :: :ok | {:error, HTTPoison.AsyncResponse | HTTPoison.MaybeRedirect | HTTPoison.Response}
def delete(pit) do
  url = HTTP.generate_url("_pit", ES.no_index(), HTTP.no_options())

  with {:ok, payload} <- Poison.encode(%{"id" => pit}),
        %HTTPoison.Response{status_code: 200} <-
          HTTPoison.request!(:delete, url, payload, HTTP.headers(HTTP.json_encoding())) do
    :ok
  else
    error -> {:error, error}
  end
end Our basic query is enhanced with three extra parameters: Now that the PIDs are sorted out, our next order of business is figuring out how to leverage them in our queries. size of 10,000 (the maximum allowed by elastic search) pit, a hash that contains %{id: <id>, keep_alive: “1m”} sort, a hash that contains %{_shard_doc: “desc”} (For sort, you need to provide something and is baked into every Elastic search index so that’s nice and portable.) _shard_doc @spec initial(PIT.pit_t(), ES.query_t()) :: ES.query_t()
def initial(pit, query) do
  %{
    query: query,
    pit: %{id: pit, keep_alive: PIT.expiration()},
    size: ES.max_results(),
    sort: %{"_shard_doc" => "desc"}
  }
end The trick here is that we feed into the next query the value of our sort field from the last hit of the previous result, like so: With our basic query down, we can focus on how to generate the sequence of queries that will extract all the items that satisfy our search criteria. @spec update(ES.query_t(), ES.response_t()) :: ES.query_t()
def update(query, %Req.Response{body: %{"hits" => %{"hits" => hits}}, status: 200}) do
  Map.put(query, :search_after, List.last(hits)["sort"])
end Armed with these two query-generating functions, we can code up that will pull all the results out of our desired index: Stream.iterator @spec streamer(ES.query_t()) :: {:ok, Enumerable.t()} | {:error, any}
def streamer(initial) do
  {:ok,
    initial
    |> search()
    |> Stream.iterate(fn previous -> search(Query.update(initial, previous)) end)
   }
rescue
  error -> {:error, error}
end We need a high-level function that takes the results from this function and produces a Stream of hits. But there’s a wrinkle — we have to delete the PIT when we are done with the Stream. But how will we know? The solution is to pass in a consumer that consumes the Stream and then we delete the PIT afterward, like so: @spec stream_many(ES.query_t(), ES.index_t(), ES.consumer_t(), non_neg_integer()) :: {:error, any()} | {:ok, Enumerable.t()}
def stream_many(query, index, consumer, count) do
  case PIT.create(index) do
    {:ok, pit_id} ->
      try do
        case pit_id |> Query.initial(query) |> streamer() do
          {:ok, stream} ->
            stream
            |> Stream.flat_map(& &1.body["hits"]["hits"])
            |> Stream.take(count)
            |> then(consumer)
          error -> error
        end
      after
        PIT.delete(pit_id)
      end
    error -> error
  end
rescue
  error -> {:error, error}
end But if our query returns less than 10k results, we don’t need the whole PID/sort/search_after machinery — one query will do the trick. @spec stream_one(ES.query_t(), ES.index_t(), ES.consumer_t()) :: {:ok, any()} | {:error, any()}
def stream_one(query, index, consumer) do
  query
  |> search(index)
  |> HTTP.on_200(fn body -> consumer.(body["hits"]["hits"]) end)
end Now we need a top-level function that query the size of the result and chooses between or depending on the value, like so: stream_one stream_many @spec stream(ES.query_t(), ES.index_t(), ES.consumer_t()) :: {:ok, any()} | {:error, any()}
def stream(query, index, consumer) do
  case count(query, index) do
    {:ok, count} ->
      if count > ES.max_results() do
        stream_many(query, index, consumer, count)
      else
        stream_one(query, index, consumer)
      end
    error ->
      error
  end
end AWS S3 The library we use to access is It handles all the low-level details for us but it does have one requirement: . Amazon S3 ex_aws_s3. the input data stream must be chunks of at least 4 Mbytes To accomplish this, we use the Stream function . This takes four inputs: chunk_while the enumerable to be chunked the initial value of the accumulator the step function a finalizer function Our first decision is, what should the accumulator look like that gets passed forward by the step function? It obviously should contain the list of the items in the current chunk. But more subtly, it should also contain the size of the current chunk so we don’t waste resources recomputing it each time. So that gives us a two-element tuple containing a list and an integer. Next, we turn our attention to the function. It should check if the current size is greater than or equal to the desired chunk size. If it is, we should take the list of items from the accumulator and convert them into a chunk using ; if not, we should add it to the current chunk (and update the size) using step convert add_chunk. What should do? Just push the item onto the front of a list and increase the value of by the current chunk’s size. add_chunk size The behaviour of depends on whether we care about the order of the items in the chunk being preserved in the output because the items in the list will be in reverse order so need to be reversed. But if we don’t care, we can skip that transformation. Putting this all together gives us: convert @spec chunker(Enumerable.t(), non_neg_integer(), boolean(), (any() -> non_neg_integer()), (Enumerable.t() -> any())) :: Enumerable.t()
def chunker(
        chunks,
        chunk_size,
        ordered \\ true,
        sizer \\ &String.length/1,
        joiner \\ &Enum.join/1
      ) do
  zero = {0, []}
  convert =
    if ordered do
      fn chunks -> chunks |> Enum.reverse() |> then(joiner) end
    else
      joiner
    end

  final = fn {_, chunks} -> {:cont, convert.(chunks), zero} end
  add_chunk = fn {size, chunks}, chunk -> {size + sizer.(chunk), [chunk | chunks]} end

  step = fn chunk, accum = {size, chunks} ->
    if size >= chunk_size do
      {:cont, convert.(chunks), add_chunk.(zero, chunk)}
    else
      {:cont, add_chunk.(accum, chunk)}
    end
  end

  Stream.chunk_while(chunks, zero, step, final)
end We can now combine all the components we have written to produce a simple controller action that requests an output stream of hits from our Elasticsearch section into 4M chunks that will satisfy the requirement of the ExAWS.S3 module: defmodule Controller do
  @four_megabytes 4*1024*1024

  def find_all(params) do
    query(params) |> ElasticSearch.stream(params.index, &consumer(params, &1))
  end
  
  def query(params) do
    %{term: %{params.query_term => params.query_value}}
  end
  
  def consumer(params, stream) do
    stream
    |> Stream.map(&Poison.encode!(&1["_source"]))
    |> chunker(@four_megabytes, false)
    |> S3.upload(params.bucket, params.filename)
    |> ExAws.request()
  end
end And that wraps up our exploration of Elixir streams, Elasticsearch, and AWS S3. I hope you enjoyed it! By Lob Staff Engineer, Guy Argo.

A Look at Using Elixir Streams, Elasticsearch & AWS S3

Say Goodbye to Kubernetes and Hello to Nomad!

At , we currently use as our deployment platform, a “roll your own Platform-as-a-Service” that you can install to handle container orchestration on AWS’s ECS (Elastic Container Service). Lob Convox Convox is showing its age, and this year we began the process of replacing Convox with HashiCorp’s , a flexible workload orchestrator to deploy and manage our containers on AWS. Nomad As we prepared our migration to Nomad, our biggest concern was performance. We started our tests with a barebones proof-of-concept setup of our API in Nomad. We benchmarked and compared the two systems and found Nomad was running slower. This was extremely surprising as Convox (which leverages AWS Elastic Container Services) and Nomad both use Docker containers under the covers. We assumed going from older to newer technology would result in some performance gains. Why Is Our Performance Suffering? Due to the stripped-down Nomad cluster, we were initially not set up with Datadog’s agent to collect application traces and profiles. Our initial performance testing revealed that every request performed poorly with a four-second delay regardless of load, which was unexpected. Even stranger, running a load test showed performance got better and would go up and down over time. Internally, we debated whether poor database performance was the cause. However, with the time-honored process of deleting code and observing the results, we found that the four-second delay occurred on save requests to our AWS S3 bucket. To determine if the problem was in our code or the infrastructure we needed to isolate the suspect code and configure Datadog to effectively trace interactions between our app and the infrastructure. We did this by extracting the S3 upload method from our production codebase to eliminate noise in our trace, configuring the Datadog APM trace library for this code, and enabling the Datadog agent on our Nomad cluster. We found 4 sequential calls with exclamation marks in Datadog. Why would an S3 upload cause 4 HTTP PUT requests? And why did each request fail after exactly 1 second? Looking closer, we found socket hang-ups and an IP address being called. The AWS JavaScript SDK makes 4 attempts to call the Elastic Compute Cloud (EC2) metadata service (that’s the 169.254.169.254 IP address), then gives up and tries something else before successfully uploading the file to S3. This exonerated our developers as it clearly wasn’t a problem with our code. Something wasn’t right with our infrastructure. Let’s zoom out for a minute and discuss how Amazon services share information with each other.  All AWS API requests have to be signed with credentials that tie back to an IAM Role with specific permissions, like uploading objects to our AWS S3 bucket for example. Traditionally, this role would be associated with access keys and those credentials would be loaded into your application -- . potentially exposing them AWS provides a more secure mechanism when the calls originate from an AWS service. For our existing Convox services, this was ECS Container Instance Roles. For services running on ECS with an associated instance role, the AWS SDK would automatically call the metadata API on our ECS cluster to get temporary credentials it can use to access other Amazon services like S3. This means we don’t need to include our AWS credentials in our code and the IAM permissions can be directly tied to the ECS service itself. For EC2, there exist EC2 Instance Profiles, which function almost the same. Almost. Why Can’t, Can’t, Can’t, Can’t, and Finally Can the AWS Sdk Reach the Metadata API on My EC2 Instance? So, why are the calls to the EC2 metadata service failing, yet somehow still succeeding in the end?  After hours of tearing through all the JavaScript AWS SDK documentation and finding nothing, we turned to Google. Searching for the IP address we’d seen in Datadog led to documentation on the EC2 instance metadata API: The AWS SDKs use IMDSv2 calls by default. If the IMDSv2 call receives no response, the SDK retries the call and, if still unsuccessful, uses IMDSv1. This can result in a delay. In a container environment, if the hop limit is 1, the IMDSv2 response does not return because going to the container is considered an additional network hop. To avoid the process of falling back to IMDSv1 and the resultant delay, in a container environment we recommend that you set the hop limit to 2. For more information, see . Configure the instance metadata options Translation: In order for the SDK, running in a Nomad-orchestrated container, to obtain credentials it must pass through the EC2 instance to reach EC2 metadata API. This counts as two “hops” and the default hop limit is one! We changed the hop limit to two and the request time dropped from 4 seconds to 85ms. Here is the Datadog APM trace after increasing the hop limit to two: What’s Wrong With This Picture? To put it bluntly, EC2 instance profiles are not the proper way to provide credentials to applications running in a container orchestrator. They are too coarse-grained. Permissions are granted to applications running on the EC2 instance, not a specific application or service. all After all, that’s why ECS, which runs on EC2 instances and therefore could use the EC2 instance profiles, instead relies on ECS instance profiles. So why did we? Because we needed a temporary solution in order to trial our proof-of-concept Nomad cluster, and EC2 instance profiles were tantalizingly similar to ECS instance profiles -- our bread-and-butter solution in Convox. Oh, and they work. The application was able to access the private S3 bucket. Well, eventually. Mostly. do The problem is the AWS JavaScript SDK call eventually succeeds which masks the underlying issue. This violates the . Basically, a system should behave in a way that most users will expect it to behave. principle of least surprise The behavior should not astonish or surprise users. You could describe the SDK behavior as a pseudo-silent failure. Our application performance was severely degraded and we were unaware anything had gone wrong. As developers, we expect things to succeed or fail, not mostly fail and then succeed. You might be wondering why isn’t AWS setting the hop limit default higher. We don’t know for certain, but our guess would be for security purposes. A low default hop limit ensures that credential requests originate inside the EC2 instance and forces developers to make a choice to increase the hop limit and be aware of any associated risks. Conclusion Several lessons can be drawn from our experience tracking down this performance issue. Regularly test the performance of your application Use modern tools like Datadog when investigating performance issues Isolate suspect code to remove the noise and observe the signal Dig into the documentation Google can help your investigation when you uncover unique clues (but you already knew that)

How Datadog Revealed Hidden AWS Performance Problems

Profound Ignorance in the Age of AI: Lobste.rs as a Case Study

This is Part 8 of a 11-part series based on the research paper “Reinforcement Learning In Agent-based Market Simulation: Unveiling Realistic Stylized Facts And Behavior”. Use the table of links below to navigate to the next part. Table of Links Part 1: Abstract & Introduction Part 2: Important Concepts Part 3: System Description Part 4: Agents & Simulation Details Part 5: Experiment Design Part 6: Continual Learning Part 7: Experiment Results Part 8: Market and Agent Responsiveness to External Events Part 9: Conclusion & References Part 10: Additional Simulation Results Part 11: Simulation Configuration 5.2 Market and Agent Responsiveness to External Events In the first experiment, we introduce a rule-based agent which performs a sequence of “flash sales”. During a flash sale event, this agent continuously sends sell orders (300 lots each) every second for a duration of 5 seconds. Then, the agent remains inactive for 400 seconds to allow the market to recover. The goal is to study how the market moves during and after the flash sale events and how the agents’ behavior changes after training with these events. Figure 7 depicts the price movement after the start of flash sale events. To create these plots we use the average price of multiple simulations normalized by the price at which flash sale started. The untrained group shows a significant and permanent price drop in contrast to the testing and continual training groups. In the testing group, prices recover to pre-flash-sale levels. However, the continual training group shows more realistic trajectories, with prices dropping and recovering to levels lower than the pre-sale prices. This price pattern aligns with descriptions of permanent and temporary price impact in [24]. We are also interested in how RL agents’ policy functions are affected when trained with flash sale events. Recall the action symmetric tweak and asymmetric tweak parameters control the prices of the limit orders sent by MM’s (see (1) and illustration in Figure 1). Intuitively, a larger symmetric tweak makes the agent place orders away from the best bid and ask (more conservatively). A positive asymmetric tweak indicates that the MM expects future higher prices than the current one, while a negative value indicates the MM expects the market to go down. When a flash sale event happens, market sell orders take liquidity from the bid side of the LOB and this results in an imbalanced LOB. In contrast, a balanced LOB means the volumes on the buy and sell sides are comparable. To determine the MM agents’ reaction we collect the states with balanced and imbalanced LOBs, and feed these states to the different agents’ policy functions. Figure 8 shows the action symmetric tweak values in the top row and the asymmetric tweak in the bottom row. We can see that when the order book is balanced the three groups output a similar distribution of actions (Figure 8b and 8d). However, when fed imbalanced LOBs (Figures 8a and 8c), the agents in the continual training group output higher symmetric price tweaks and lower asymmetric price tweaks, compared with the agents in the two other groups. Thus when a flash sale event is detected, the MM agents in the continual learning group tend to place orders deeper into the LOB and move the expected price equilibrium downward. This behavior aligns with the findings in literature [25, 26, 27]. These results show that the agents can adapt to different market conditions through continual learning. In this experiment, we only use continual learning Group A MM agents, as they need to adapt to changing market conditions. The LT agents are also from Group A but their reward function is changed through the evolution of the target buy/sell parameters. Specifically, Figure 9 shows the price process resulting from the activity of these informed LT agents. The four phases separated by dashed red lines are: Sell (0.3/0.4), Buy (0.4/0.35), Balanced buy and sell (0.4/0.4), and last Buy (0.4/0.3), the numbers in parenthesis indicate (buy fraction/sell fraction). We expect to see the price movement aligning with the target buy/sell parameters. Additionally, similar to the previous study we collect states in the first and the last phases (i.e., steps 0-10,000 when the price goes down and steps 30,000-36,000 when the price goes up). We feed these states to the MM’s policy function at the beginning of the day (Before) and at the end of the trading day (After). Figure 10 shows the distributions of the outputs in action symmetric and asymmetric tweak. In both scenarios when the price is going down and when the price is going up, the action symmetric tweak (top row) gets larger, thus the MM agent becomes more conservative and tends to enlarge the spread. This aligns with the findings in the previous experiment. We can also see that the distribution of price asymmetric tweak becomes negative when prices are going down and becomes positive when prices are going up. This means the learned agents change their expectations of future prices along with the observed market direction. In contrast, the asymmetric tweak average is close to zero for agents that are not continuously trained. This helps explain why the price tends to come back to pre-flash-sale values for the agents in Group B in Figure 7. Authors:
(1) Zhiyuan Yao, Stevens Institute of Technology, Hoboken, New Jersey, USA (zyao9@stevens.edu);
(2) Zheng Li, Stevens Institute of Technology, Hoboken, New Jersey, USA (zli149@stevens.edu);
(3) Matthew Thomas, Stevens Institute of Technology, Hoboken, New Jersey, USA (mthomas3@stevens.edu);
(4) Ionut Florescu, Stevens Institute of Technology, Hoboken, New Jersey, USA (ifloresc@stevens.edu). This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. This is Part 8 of a 11-part series based on the research paper “Reinforcement Learning In Agent-based Market Simulation: Unveiling Realistic Stylized Facts And Behavior”. Use the table of links below to navigate to the next part. This is Part 8 of a 11-part series based on the research paper “ Reinforcement Learning In Agent-based Market Simulation: Unveiling Realistic Stylized Facts And Behavior ”. Use the table of links below to navigate to the next part. Part 8 Reinforcement Learning In Agent-based Market Simulation: Unveiling Realistic Stylized Facts And Behavior Table of Links Part 1: Abstract & Introduction Part 1: Abstract & Introduction Part 2: Important Concepts Part 2: Important Concepts Part 3: System Description Part 3: System Description Part 4: Agents & Simulation Details Part 4: Agents & Simulation Details Part 5: Experiment Design Part 5: Experiment Design Part 6: Continual Learning Part 6: Continual Learning Part 7: Experiment Results Part 7: Experiment Results Part 8: Market and Agent Responsiveness to External Events Part 8: Market and Agent Responsiveness to External Events Part 9: Conclusion & References Part 9: Conclusion & References Part 10: Additional Simulation Results Part 10: Additional Simulation Results Part 11: Simulation Configuration Part 11: Simulation Configuration 5.2 Market and Agent Responsiveness to External Events In the first experiment, we introduce a rule-based agent which performs a sequence of “flash sales”. During a flash sale event, this agent continuously sends sell orders (300 lots each) every second for a duration of 5 seconds. Then, the agent remains inactive for 400 seconds to allow the market to recover. The goal is to study how the market moves during and after the flash sale events and how the agents’ behavior changes after training with these events. Figure 7 depicts the price movement after the start of flash sale events. To create these plots we use the average price of multiple simulations normalized by the price at which flash sale started. The untrained group shows a significant and permanent price drop in contrast to the testing and continual training groups. In the testing group, prices recover to pre-flash-sale levels. However, the continual training group shows more realistic trajectories, with prices dropping and recovering to levels lower than the pre-sale prices. This price pattern aligns with descriptions of permanent and temporary price impact in [24]. We are also interested in how RL agents’ policy functions are affected when trained with flash sale events. Recall the action symmetric tweak and asymmetric tweak parameters control the prices of the limit orders sent by MM’s (see (1) and illustration in Figure 1). Intuitively, a larger symmetric tweak makes the agent place orders away from the best bid and ask (more conservatively). A positive asymmetric tweak indicates that the MM expects future higher prices than the current one, while a negative value indicates the MM expects the market to go down. When a flash sale event happens, market sell orders take liquidity from the bid side of the LOB and this results in an imbalanced LOB. In contrast, a balanced LOB means the volumes on the buy and sell sides are comparable. To determine the MM agents’ reaction we collect the states with balanced and imbalanced LOBs, and feed these states to the different agents’ policy functions. Figure 8 shows the action symmetric tweak values in the top row and the asymmetric tweak in the bottom row. We can see that when the order book is balanced the three groups output a similar distribution of actions (Figure 8b and 8d). However, when fed imbalanced LOBs (Figures 8a and 8c), the agents in the continual training group output higher symmetric price tweaks and lower asymmetric price tweaks, compared with the agents in the two other groups. Thus when a flash sale event is detected, the MM agents in the continual learning group tend to place orders deeper into the LOB and move the expected price equilibrium downward. This behavior aligns with the findings in literature [25, 26, 27]. These results show that the agents can adapt to different market conditions through continual learning. In this experiment, we only use continual learning Group A MM agents, as they need to adapt to changing market conditions. The LT agents are also from Group A but their reward function is changed through the evolution of the target buy/sell parameters. Specifically, Figure 9 shows the price process resulting from the activity of these informed LT agents. The four phases separated by dashed red lines are: Sell (0.3/0.4), Buy (0.4/0.35), Balanced buy and sell (0.4/0.4), and last Buy (0.4/0.3), the numbers in parenthesis indicate (buy fraction/sell fraction). We expect to see the price movement aligning with the target buy/sell parameters. Additionally, similar to the previous study we collect states in the first and the last phases (i.e., steps 0-10,000 when the price goes down and steps 30,000-36,000 when the price goes up). We feed these states to the MM’s policy function at the beginning of the day (Before) and at the end of the trading day (After). Figure 10 shows the distributions of the outputs in action symmetric and asymmetric tweak. In both scenarios when the price is going down and when the price is going up, the action symmetric tweak (top row) gets larger, thus the MM agent becomes more conservative and tends to enlarge the spread. This aligns with the findings in the previous experiment. We can also see that the distribution of price asymmetric tweak becomes negative when prices are going down and becomes positive when prices are going up. This means the learned agents change their expectations of future prices along with the observed market direction. In contrast, the asymmetric tweak average is close to zero for agents that are not continuously trained. This helps explain why the price tends to come back to pre-flash-sale values for the agents in Group B in Figure 7. Authors: (1) Zhiyuan Yao, Stevens Institute of Technology, Hoboken, New Jersey, USA (zyao9@stevens.edu); (2) Zheng Li, Stevens Institute of Technology, Hoboken, New Jersey, USA (zli149@stevens.edu); (3) Matthew Thomas, Stevens Institute of Technology, Hoboken, New Jersey, USA (mthomas3@stevens.edu); (4) Ionut Florescu, Stevens Institute of Technology, Hoboken, New Jersey, USA (ifloresc@stevens.edu). Authors: Authors: (1) Zhiyuan Yao, Stevens Institute of Technology, Hoboken, New Jersey, USA (zyao9@stevens.edu); (2) Zheng Li, Stevens Institute of Technology, Hoboken, New Jersey, USA (zli149@stevens.edu); (3) Matthew Thomas, Stevens Institute of Technology, Hoboken, New Jersey, USA (mthomas3@stevens.edu); (4) Ionut Florescu, Stevens Institute of Technology, Hoboken, New Jersey, USA (ifloresc@stevens.edu). This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. available on arxiv

RL Agents Adapt to Flash Sale Events & Imbalanced Limit Order Books (LOBs)

The Crypto Lobby Seeks to Influence US Politics: A Peek at Their Smear Campaign and False Narrative

Alice in Wonderland by Lewis Carroll, is part of the HackerNoon Books Series. You can jump to any chapter in this book . The Lobster Quadrille here CHAPTER X. The Lobster Quadrille The Mock Turtle sighed deeply, and drew the back of one flapper across his eyes. He looked at Alice, and tried to speak, but for a minute or two sobs choked his voice. “Same as if he had a bone in his throat,” said the Gryphon: and it set to work shaking him and punching him in the back. At last the Mock Turtle recovered his voice, and, with tears running down his cheeks, he went on again:— “You may not have lived much under the sea—” (“I haven’t,” said Alice)—“and perhaps you were never even introduced to a lobster—” (Alice began to say “I once tasted—” but checked herself hastily, and said “No, never”) “—so you can have no idea what a delightful thing a Lobster Quadrille is!” “No, indeed,” said Alice. “What sort of a dance is it?” “Why,” said the Gryphon, “you first form into a line along the sea-shore—” “Two lines!” cried the Mock Turtle. “Seals, turtles, salmon, and so on; then, when you’ve cleared all the jelly-fish out of the way—” “ generally takes some time,” interrupted the Gryphon. That “—you advance twice—” “Each with a lobster as a partner!” cried the Gryphon. “Of course,” the Mock Turtle said: “advance twice, set to partners—” “—change lobsters, and retire in same order,” continued the Gryphon. “Then, you know,” the Mock Turtle went on, “you throw the—” “The lobsters!” shouted the Gryphon, with a bound into the air. “—as far out to sea as you can—” “Swim after them!” screamed the Gryphon. “Turn a somersault in the sea!” cried the Mock Turtle, capering wildly about. “Change lobsters again!” yelled the Gryphon at the top of its voice. “Back to land again, and that’s all the first figure,” said the Mock Turtle, suddenly dropping his voice; and the two creatures, who had been jumping about like mad things all this time, sat down again very sadly and quietly, and looked at Alice. “It must be a very pretty dance,” said Alice timidly. “Would you like to see a little of it?” said the Mock Turtle. “Very much indeed,” said Alice. “Come, let’s try the first figure!” said the Mock Turtle to the Gryphon. “We can do without lobsters, you know. Which shall sing?” “Oh, sing,” said the Gryphon. “I’ve forgotten the words.” you So they began solemnly dancing round and round Alice, every now and then treading on her toes when they passed too close, and waving their forepaws to mark the time, while the Mock Turtle sang this, very slowly and sadly:— “Will you walk a little faster?” said a whiting to a snail. “There’s a porpoise close behind us, and he’s treading on my tail. See how eagerly the lobsters and the turtles all advance! They are waiting on the shingle—will you come and join the dance? Will you, won’t you, will you, won’t you, will you join the dance? Will you, won’t you, will you, won’t you, won’t you join the dance? “You can really have no notion how delightful it will be When they take us up and throw us, with the lobsters, out to sea!” But the snail replied “Too far, too far!” and gave a look askance— Said he thanked the whiting kindly, but he would not join the dance. Would not, could not, would not, could not, would not join the dance. Would not, could not, would not, could not, could not join the dance. “What matters it how far we go?” his scaly friend replied. “There is another shore, you know, upon the other side. The further off from England the nearer is to France— Then turn not pale, beloved snail, but come and join the dance. Will you, won’t you, will you, won’t you, will you join the dance? Will you, won’t you, will you, won’t you, won’t you join the dance?” “Thank you, it’s a very interesting dance to watch,” said Alice, feeling very glad that it was over at last: “and I do so like that curious song about the whiting!” “Oh, as to the whiting,” said the Mock Turtle, “they—you’ve seen them, of course?” “Yes,” said Alice, “I’ve often seen them at dinn—” she checked herself hastily. “I don’t know where Dinn may be,” said the Mock Turtle, “but if you’ve seen them so often, of course you know what they’re like.” “I believe so,” Alice replied thoughtfully. “They have their tails in their mouths—and they’re all over crumbs.” “You’re wrong about the crumbs,” said the Mock Turtle: “crumbs would all wash off in the sea. But they their tails in their mouths; and the reason is—” here the Mock Turtle yawned and shut his eyes.—“Tell her about the reason and all that,” he said to the Gryphon. have “The reason is,” said the Gryphon, “that they go with the lobsters to the dance. So they got thrown out to sea. So they had to fall a long way. So they got their tails fast in their mouths. So they couldn’t get them out again. That’s all.” would “Thank you,” said Alice, “it’s very interesting. I never knew so much about a whiting before.” “I can tell you more than that, if you like,” said the Gryphon. “Do you know why it’s called a whiting?” “I never thought about it,” said Alice. “Why?” “ ,” the Gryphon replied very solemnly. It does the boots and shoes Alice was thoroughly puzzled. “Does the boots and shoes!” she repeated in a wondering tone. “Why, what are shoes done with?” said the Gryphon. “I mean, what makes them so shiny?” your Alice looked down at them, and considered a little before she gave her answer. “They’re done with blacking, I believe.” “Boots and shoes under the sea,” the Gryphon went on in a deep voice, “are done with a whiting. Now you know.” “And what are they made of?” Alice asked in a tone of great curiosity. “Soles and eels, of course,” the Gryphon replied rather impatiently: “any shrimp could have told you that.” “If I’d been the whiting,” said Alice, whose thoughts were still running on the song, “I’d have said to the porpoise, ‘Keep back, please: we don’t want with us!’” you “They were obliged to have him with them,” the Mock Turtle said: “no wise fish would go anywhere without a porpoise.” “Wouldn’t it really?” said Alice in a tone of great surprise. “Of course not,” said the Mock Turtle: “why, if a fish came to , and told me he was going a journey, I should say ‘With what porpoise?’” me “Don’t you mean ‘purpose’?” said Alice. “I mean what I say,” the Mock Turtle replied in an offended tone. And the Gryphon added “Come, let’s hear some of adventures.” your “I could tell you my adventures—beginning from this morning,” said Alice a little timidly: “but it’s no use going back to yesterday, because I was a different person then.” “Explain all that,” said the Mock Turtle. “No, no! The adventures first,” said the Gryphon in an impatient tone: “explanations take such a dreadful time.” So Alice began telling them her adventures from the time when she first saw the White Rabbit. She was a little nervous about it just at first, the two creatures got so close to her, one on each side, and opened their eyes and mouths so wide, but she gained courage as she went on. Her listeners were perfectly quiet till she got to the part about her repeating “ ,” to the Caterpillar, and the words all coming different, and then the Mock Turtle drew a long breath, and said “That’s very curious.” very You are old, Father William “It’s all about as curious as it can be,” said the Gryphon. “It all came different!” the Mock Turtle repeated thoughtfully. “I should like to hear her try and repeat something now. Tell her to begin.” He looked at the Gryphon as if he thought it had some kind of authority over Alice. “Stand up and repeat ‘’ ,’” said the Gryphon. Tis the voice of the sluggard “How the creatures order one about, and make one repeat lessons!” thought Alice; “I might as well be at school at once.” However, she got up, and began to repeat it, but her head was so full of the Lobster Quadrille, that she hardly knew what she was saying, and the words came very queer indeed:— “’Tis the voice of the Lobster; I heard him declare, “You have baked me too brown, I must sugar my hair.” As a duck with its eyelids, so he with his nose Trims his belt and his buttons, and turns out his toes.” [later editions continued as follows When the sands are all dry, he is gay as a lark, And will talk in contemptuous tones of the Shark, But, when the tide rises and sharks are around, His voice has a timid and tremulous sound.] “That’s different from what used to say when I was a child,” said the Gryphon. I “Well, I never heard it before,” said the Mock Turtle; “but it sounds uncommon nonsense.” Alice said nothing; she had sat down with her face in her hands, wondering if anything would happen in a natural way again. ever “I should like to have it explained,” said the Mock Turtle. “She can’t explain it,” said the Gryphon hastily. “Go on with the next verse.” “But about his toes?” the Mock Turtle persisted. “How he turn them out with his nose, you know?” could “It’s the first position in dancing.” Alice said; but was dreadfully puzzled by the whole thing, and longed to change the subject. “Go on with the next verse,” the Gryphon repeated impatiently: “it begins ‘ .’” I passed by his garden Alice did not dare to disobey, though she felt sure it would all come wrong, and she went on in a trembling voice:— “I passed by his garden, and marked, with one eye, How the Owl and the Panther were sharing a pie—” [later editions continued as follows The Panther took pie-crust, and gravy, and meat, While the Owl had the dish as its share of the treat. When the pie was all finished, the Owl, as a boon, Was kindly permitted to pocket the spoon: While the Panther received knife and fork with a growl, And concluded the banquet—] “What the use of repeating all that stuff,” the Mock Turtle interrupted, “if you don’t explain it as you go on? It’s by far the most confusing thing ever heard!” is I “Yes, I think you’d better leave off,” said the Gryphon: and Alice was only too glad to do so. “Shall we try another figure of the Lobster Quadrille?” the Gryphon went on. “Or would you like the Mock Turtle to sing you a song?” “Oh, a song, please, if the Mock Turtle would be so kind,” Alice replied, so eagerly that the Gryphon said, in a rather offended tone, “Hm! No accounting for tastes! Sing her ‘ ,’ will you, old fellow?” Turtle Soup The Mock Turtle sighed deeply, and began, in a voice sometimes choked with sobs, to sing this:— “Beautiful Soup, so rich and green, Waiting in a hot tureen! Who for such dainties would not stoop? Soup of the evening, beautiful Soup! Soup of the evening, beautiful Soup! Beau—ootiful Soo—oop! Beau—ootiful Soo—oop! Soo—oop of the e—e—evening, Beautiful, beautiful Soup! “Beautiful Soup! Who cares for fish, Game, or any other dish? Who would not give all else for two p ennyworth only of beautiful Soup? Pennyworth only of beautiful Soup? Beau—ootiful Soo—oop! Beau—ootiful Soo—oop! Soo—oop of the e—e—evening, Beautiful, beauti—FUL SOUP!” “Chorus again!” cried the Gryphon, and the Mock Turtle had just begun to repeat it, when a cry of “The trial’s beginning!” was heard in the distance. “Come on!” cried the Gryphon, and, taking Alice by the hand, it hurried off, without waiting for the end of the song. “What trial is it?” Alice panted as she ran; but the Gryphon only answered “Come on!” and ran the faster, while more and more faintly came, carried on the breeze that followed them, the melancholy words:— “Soo—oop of the e—e—evening, Beautiful, beautiful Soup!” About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Lewis Carroll (2008). Alice in Wonderland. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/11/pg11-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at www.gutenberg.org https://www.gutenberg.org/policy/license.html.

Stories, News & Mentions about LOB

Categories

Trending Topics

Stories, News & Mentions about LOB

Lob’s Stories on HackerNoon

Lob's News & Mentions

Categories

Trending Topics