AndreiCalazans

  const renderItem = useCallback(
    ({ item: { node } }) => {
      const slug = node.slug;
      const handlePress = () => {
        push('SignedOutAssetScreen', { assetSlug: slug });
      };

AndreiCalazans

export default async function tryCatch<Data>(
  promise: Promise<Data>,
): Promise<{ error: Error } | { data: Data }> {
  try {
    return { data: await promise };
  } catch (error) {
    return { error };
  }
}

AndreiCalazans

HTTP Streaming (or Chunked vs Store & Forward)

The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.

However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on

AndreiCalazans

For better developer experience always prefer an explicit pattern.

There is an overhead with understanding implicit code. It implies that you know a contextual knowledge not written in front of you.

JavaScript Throwable Functions

In JavaScript, we have no way of signaling if a given function will throw or not. This is the implicitness of calling a function.

AndreiCalazans

import React, { Component } from "react";
import {
    requireNativeComponent,
    UIManager,
    findNodeHandle,
    NativeModules,
} from "react-native";

const MKPlayerView = requireNativeComponent("MKPlayerView");

AndreiCalazans

thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x0000000100ccb35d EpgTestApp`yi::epg::TimeMarkerView::ResetMarkerGap(this=0x7261206f77742064) at TimeMarkerView.cpp:110:9
    frame #1: 0x0000000100c0e46c EpgTestApp`yi::epg::ChannelListAdapter::UpdateTimeMarkerGap(this=0x000000010e9eb420) at ChannelListAdapter.cpp:274:31
    frame #2: 0x0000000100c16298 EpgTestApp`yi::epg::ChannelListAdapter::ChannelListAdapter(this=0x000000010e9eb868)::$_0::operator()() const at ChannelListAdapter.cpp:43:9
    frame #3: 0x0000000100c16276 EpgTestApp`void CYISignalCallableConnection<yi::epg::ChannelListAdapter::ChannelListAdapter(yi::epg::EPGListView*)::$_0>::EmitInternal<>(this=0x000000010e9eb840, (null)=0x0000000000000000, args=size=0) at YiSignalCallableConnection.h:68:9
    frame #4: 0x0000000100c16106 EpgTestApp`CYISignalCallableConnection<yi::epg::ChannelListAdapter::ChannelListAdapter(yi::epg::EPGListView*)::$_0>::Emit(this=0x000000010e9eb840) at YiSignalCalla

AndreiCalazans

export function fromSecondsToHHMMSS(value: string) {
    const sec = parseInt(value, 10); // convert value to number if it's string
    const hours   = Math.floor(sec / 3600); // get hours
    const minutes = Math.floor((sec - (hours * 3600)) / 60); // get minutes
    const seconds = sec - (hours * 3600) - (minutes * 60); //  get seconds
    // add 0 if value < 10; Example: 2 => 02
    function padWithZero(val: number) {
      if (val < 10) {
        return `0${val}`;
      }

AndreiCalazans

⬢ G2i NodeJS Test

Messaging acronyms are everywhere now. Do you know all of them?

Build a REST API for the World Texting Foundation, also known as WTF.

A sample JSON data file will be provided with a base set of acronym definitions. We expect you to create a NodeJS server using modern best practices for API development. Please consider the recommendations attached as this will list the items we are looking for above.

AndreiCalazans

function makeRoute(route, params) {
  return {
    route,
    params,
  };
}

class StateManager {
  constructor(initialState) {
    let subscriptions = [];

AndreiCalazans

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.