heitorlessa

from __future__ import annotations

from typing import List, Optional

from aws_lambda_powertools.utilities.parser.models import EventBridgeModel
from aws_lambda_powertools.utilities.parser.envelopes import (
    EventBridgeEnvelope,  # only if you want to discard EventBridge metadata
)
from aws_lambda_powertools.utilities.parser.parser import event_parser
from pydantic import BaseModel

danilop

#!/usr/bin/env python

import boto3
import argparse
from operator import itemgetter
from collections import defaultdict


def nested_defaultdict():
        return defaultdict(nested_defaultdict)

levelsio

<?
	# MIT license, do whatever you want with it
	#
	# This is my invoice.php page which I use to make invoices that customers want,
	# with their address on it and which are easily printable. I love Stripe but
	# their invoices and receipts were too wild for my customers on Remote OK
	#
	
	require_once(__DIR__.'/../vendor/autoload.php');

tykurtz

GROKKING NOTES

I liked the way Grokking the coding interview organized problems into learnable patterns. However, the course is expensive and the majority of the time the problems are copy-pasted from leetcode. As the explanations on leetcode are usually just as good, the course really boils down to being a glorified curated list of leetcode problems.

So below I made a list of leetcode problems that are as close to grokking problems as possible.

Pattern: Sliding Window

• https://leetcode.com/problems/maximum-subarray/ # Close enough
• https://leetcode.com/problems/minimum-size-subarray-sum/

ElectricRCAircraftGuy

If you are like me you find yourself cloning a repo, making some proposed changes and then deciding to later contributing back using the GitHub Flow convention. Below is a set of instructions I've developed for myself on how to deal with this scenario and an explanation of why it matters based on jagregory's gist.

To follow GitHub flow you should really have created a fork initially as a public representation of the forked repository and the clone that instead. My understanding is that the typical setup would have your local repository pointing to your fork as origin and the original forked repository as upstream so that you can use these keywords in other git commands.

1. Clone some repo (you've probably already done this step).

   git clone git@github...some-repo.git

vaginessa

For a trial reset remove the entire key:

Windows Registry Editor Version 5.00

HKEY_CURRENT_USER\Software\Classes\CLSID\{dc8137d7-6d72-3550-a000-ae9c2affc92}


after that reboot. :)

0xjac

The repository for the assignment is public and Github does not allow the creation of private forks for public repositories.

The correct way of creating a private frok by duplicating the repo is documented here.

For this assignment the commands are:

1. Create a bare clone of the repository. (This is temporary and will be removed so just do it wherever.)

git clone --bare git@github.com:usi-systems/easytrace.git

chitchcock

Stevey's Google Platforms Rant

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real