hackermondev

hi, i'm daniel. i'm a 16-year-old high school senior. in my free time, i hack billion dollar companies and build cool stuff.

about a month ago, a couple of friends and I found serious critical vulnerabilities on Mintlify, an AI documentation platform used by some of the top companies in the world.

i found a critical cross-site scripting vulnerability that, if abused, would let an attacker to inject malicious scripts into the documentation of numerous companies and steal credentials from users with a single link open.

(go read my friends' writeups (after this one))
how to hack discord, vercel, and more with one easy trick (eva)
Redacted by Counsel: A supply chain postmortem (MDL)

huytd

How to use:

./wordle.sh

Or try the unlimit mode:

pjlamb12

import { Injectable, Renderer2, Inject, RendererFactory2 } from '@angular/core';
import { DOCUMENT } from '@angular/common';
import { RuntimeConfigLoaderService } from 'runtime-config-loader';
import { Router, RouterEvent, NavigationEnd } from '@angular/router';
import { filter, tap } from 'rxjs/operators';

declare let gtag: Function;

@Injectable({
    providedIn: 'root',

getify

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

nartc

@NgModule({
  imports: [OAuthModule.forRoot({...})] // <-- how to use the configuration.json here
})
export class AppModule {
  constructor(@Inject(AppConfig) private readonly appConfig: AppConfiguration) {} // I can inject
}

NetanelBasal

import { ComponentFactoryResolver, ComponentRef, Directive, EventEmitter, Input, Type, ViewContainerRef } from '@angular/core';
import { Subscription } from 'rxjs';

@Directive({
  selector: '[lazyComp]'
})
export class LazyCompDirective {
  private _inputs;
  private _outputs;
  private subscription = new Subscription();

klement97

import {AbstractControl, FormArray, FormControl, FormGroup, ValidationErrors} from '@angular/forms';
import {Injectable} from '@angular/core';
import {debounceTime, distinctUntilChanged} from 'rxjs/operators';


export declare interface ServerError {
    [key: string]: [];
}

laughinghan

• any: magic, ill-behaved type that acts like a combination of never (the proper [bottom type]) and unknown (the proper [top type])
  • Anything except never is assignable to any, and any is assignable to anything at all.
  • Identities: any & AnyTypeExpression = any, any | AnyTypeExpression = any
  • Key TypeScript feature that allows for [gradual typing].
• unknown: proper, well-behaved [top type]
  • Anything at all is assignable to unknown. unknown is only assignable to itself (unknown) and any.
  • Identities: unknown & AnyTypeExpression = AnyTypeExpression, unknown | AnyTypeExpression = unknown

• Prefer over any whenever possible. Anywhere in well-typed code you're tempted to use any, you probably want unknown.

nartc

import {
  Compiler,
  ComponentRef,
  Directive,
  Inject,
  Injector,
  Input,
  NgModuleFactory,
  OnInit,
  Type,

nartc

Văn hoá CodersX

CodersX là một. Chúng ta hoạt động vì một mục đích duy nhất: Thay đổi thế giới một cách tích cực, bắt đầu bằng việc tạo nên một nền giáo dục miễn phí.

Vision

3. Thay đổi thế giới ← 2. Cùng nhau làm các startup có ảnh hưởng tích cực tới cuộc sống xung quanh ← 1. Làm mới hệ thống giáo dục ← 0. Giúp tất cả mọi người tiếp cận với lập trình

Giúp đỡ các thành viên trong team

Một team chỉ mạnh khi tất cả mọi người support lẫn nhau, và cùng nhau làm việc vì một mục tiêu duy nhất. Nếu chỉ nghĩ đến bản thân thì một lúc nào đó team sẽ tan rã (nếu nhiều người cùng nghĩ về bản thân), hoặc tự loại mình ra khỏi team.

Nghĩ tới người xung quanh