18 Matching Annotations
  1. Sep 2021
  2. Jul 2021
  3. datatracker.ietf.org datatracker.ietf.org
    1. The WebSocket Protocol is designed on the principle that there should be minimal framing (the only framing that exists is to make the protocol frame-based instead of stream-based and to support a distinction between Unicode text and binary frames). It is expected that metadata would be layered on top of WebSocket by the application Fette & Melnikov Standards Track [Page 9] RFC 6455 The WebSocket Protocol December 2011 layer, in the same way that metadata is layered on top of TCP by the application layer (e.g., HTTP). Conceptually, WebSocket is really just a layer on top of TCP that does the following: o adds a web origin-based security model for browsers o adds an addressing and protocol naming mechanism to support multiple services on one port and multiple host names on one IP address o layers a framing mechanism on top of TCP to get back to the IP packet mechanism that TCP is built on, but without length limits o includes an additional closing handshake in-band that is designed to work in the presence of proxies and other intermediaries Other than that, WebSocket adds nothing. Basically it is intended to be as close to just exposing raw TCP to script as possible given the constraints of the Web. It's also designed in such a way that its servers can share a port with HTTP servers, by having its handshake be a valid HTTP Upgrade request. One could conceptually use other protocols to establish client-server messaging, but the intent of WebSockets is to provide a relatively simple protocol that can coexist with HTTP and deployed HTTP infrastructure (such as proxies) and that is as close to TCP as is safe for use with such infrastructure given security considerations, with targeted additions to simplify usage and keep simple things simple (such as the addition of message semantics).
  4. Feb 2021
    1. An endpoint links your routing with your business code. The idea is that your controllers are pure HTTP routers, calling the respective endpoint for each action. From there, the endpoint takes over, handles authentication, policies, executing the domain code, interpreting the result, and providing hooks to render a response.
    1. In Trailblazer, models are completely empty. They solely contain associations and finders. No business logic is allowed in models.
    2. Trailblazer extends the conventional MVC stack in Rails. Keep in mind that adding layers doesn't necessarily mean adding more code and complexity. The opposite is the case: Controller, view and model become lean endpoints for HTTP, rendering and persistence. Redundant code gets eliminated by putting very little application code into the right layer.
    3. Trailblazer is no "complex web of objects and indirection". It solves many problems that have been around for years with a cleanly layered architecture.
  5. Dec 2020
    1. Svelte components are a thin layer over the DOM and naturally expose the web platform. Coding in Svelte feels like I’m moving with the grain of the web.
  6. May 2020
  7. Aug 2019
    1. It’s a good practice to try to keep intermittent contact with participants, even if you aren’t taking a measurement at that time, so that you’re less likely to lose track of them.

      Can we perhaps provide an in-text example, or a link to a relevant study, to illustrate the articulation of this principle/suggestion in actual research practice? While I do think this is an important suggestion, it may be difficult for some student readers to translate this suggestion into actual practice. Providing a concrete example of how to do this may also help students whose research projects could benefit from some intentional strategy for maintaining intermittent contact with participants.

    1. We also can use activities like member checking, another tool to support qualitative rigor, to ensure that our findings are accurately interpreted by vetting them with our participants prior to concluding our study.

      Reading this particular subsection on "member checking," I wasn't quite sure what this term refers to. Perhaps we can include a link, a more formal definition, or a clearer/more concrete example of "member checking" as a tool for qualitative research enhancement. Might a Student Example, or an example from the author's own research/professional experience, serve this purpose?

    1. Interviewing in-person allows you to capture important non-verbal and contextual information that will likely be limited if you choose to conduct your interview via phone or video.

      Perhaps we can list a few brief examples here to make this point a bit less abstract/vague. What specific non-verbal or contextual information might be limited during a phone or video interview? And how might the non-verbal/contextual info benefit the researcher and/or participant?

    2. This needs to be tempered with humility by allowing participants to show us if and how what we think we know about their community might apply to them as individuals.

      I sense that the author is making an important point here, but I'm not certain about the specifics. Perhaps revising the wording/sentence structure here will provide some clarity. Is this sentence saying that we should examine our own biases so that we do our best to avoid selective perception? And/or is this sentence saying that we need to be open enough to allow participants to express views that might not align with our preconceived notions? I think the wording could be tweaked so that the main point shines through. Perhaps a real-world example might help illustrate the author's point.

    1. If you do opt for this, make sure that you are not violating anyone’s right to privacy.

      May want to include a few concrete examples here. How problematic/ethical would it be for a student to collect observational data during a Narcotics Anonymous meeting, for example? Or during a religious gathering/ceremony? How about a city council meeting? We could provide just a couple/few specific real-world examples to make this point more engaging to readers.

    2. The researcher who schedules interviews with public assistance recipients to capture their experience after a legislation drastically changes their requirements for receiving benefits relies on the verbal data shared with them.

      I think this important point could perhaps be more clearly explained/worded. I think that if we separately identify the researcher's topic of interest and research approach, we'll bring some added clarity to this hypothetical scenario. Here's how I might revise this sentence to clarify core concepts and explain links between ideas:

      "Let's say, for example, that a researcher wants to learn about the experiences of public assistance recipients after federal legislation drastically changes the requirements for receiving benefits. This researcher might schedule interviews to capture verbal data shared by participants. The researcher relies on the data he or she may capture as participants talk about their personal stories, experiences, and reactions to the federal legislation."

      *The above revision suggestion references the "personal stories" of participants - which could be a good way to naturally reiterate this chapter's earlier points about qualitative research focusing in part on the stories of research subjects.

    3. As such, as you go about recruiting for your qualitative studies, remember that people are made of multiple stories, of intersectional identities.

      (I have not perused every chapter, so please take this comment with a grain of salt - I recognize that perhaps additional material is elsewhere included in the text)

      This part of the paragraph about intersectionality lacks context and clarity, I think, because there aren't concrete links between fairly abstract ideas and real-world examples. Perhaps we can add a Student Example box here that gives a couple/few examples of how researchers or students may encounter issues of intersectionality in the field/in their work)