Если вы уже посмотрели последнее видео на канале, то для вас это будет напоминанием, для всех остальных — новостью.

В последнее время большую часть моего времени занимало менторство. Ко мне приходили с разными запросами: улучшить свои навыки, закрыть пробелы, устроиться на более высокую и/или высокооплачиваемую позицию и тд. Раннее я не объявлял об этом на канале, в основном люди приходили сами, а затем, добившись результатов, советовали своим знакомым.

На данный момент я добираю людей, так как есть несколько свободных мест. Вам это может пригодиться если вы хотите:
- Выявить свои пробелы и устранить их
- Увеличить техническую экспертизу как в конкретных технологиях, так и в целом во frontend'е
- Разобрать сложные рабочие кейсы
- Подготовиться к собеседованию
- Повысить свой доход

Например, одним из наиболее популярных запросов является смена места работы со всеми сопутствующими плюшками (увеличение заработка, повышение в должности, переход в более престижную организацию).
В таком случае принцип работы выглядит примерно так:
- Мы созваниваемся и я проверяю текущий технический уровень, даю по нему обратную связь
- Далее формулируем цели, составляем исходя из них личный roadmap и вырабатываем комфортную стратегию обучения

Как записаться на менторство?
1. Заполняете форму (максимально подробно, это поможет понять мне смогу ли я вам помочь в конкретно вашей ситуации)
2. Назначаем онлайн встречу, где вы подробно сможете узнать о формате менторства и задать интересующие вас вопросы
3. Начинаем совместную работу для достижения ваших целей

Заполнить форму
Почитать отзывы учеников — @ayub_begimkulov_reviews

Друзья, хотел сообщить о том, что планирую сегодня в 15:30 по мск провести стрим. Продолжим писать проект для замера скорости печати.

В прошлый раз провели небольшой рефакторинг и добавили окно настроек. Сегодня уже займемся полноценной поддержкой кода.

У кого есть время — подключайтесь. Отвечу на все ваши вопросы в чате)

https://www.youtube.com/live/muZIxdTIYFM

Начинаем через пару минут)

Планирую сегодня в 15:30 по мск провести стрим, где мы продолжим разрабатывать наш проект для замера скорости печати.

В прошлый раз мы разобрались с тем, каким образом можно считать количество слов в коде через AST. И подготовили функцию, которая отдает все словесные токены в нашем коде.

На данном стриме планирую:
- Доделать подсчет слов для кода по новой схеме с AST
- Добавить каретку и прочие мелочи для удобства
- Попробовать сделать скрипт, который бы парсил репозиторий и на его основе создавал заготовленные примеры кода для тестов

У кого есть время — заходите. Буду отвечать на все вопросы в чате)

https://www.youtube.com/live/y8keVDARJ1M

Начинаем через пару минут!

Пару месяцев назад в очередной раз столкнулся с проблемой при попытке использовать ts-node (выдавал ERR_UNKNOWN_FILE_EXTENSION, хотя импортировал только TS файлы).

Точные детали ошибки не помню, но проблема была в том, что ts-node с не мог нормально подгрузить ESM модули при использовании ноды версии 20+. При откате на 18ю версию все работало.

В процессе поиска решения проблемы самым нормальным вариантом оказалось просто съехать с ts-node на tsx (хотя возможно уже проблему решили).

Но хочу сказать, что инструмент приятно удивил. За время работы с ним вообще никаких проблем пока не было. Работает быстро. Полностью имитирует интерфейс команды node + имеет watch режим (так что от nodemon тоже можно отказываться).

Из минусов, нет проверки типов. Связанно с тем, что под капотом используется esbuild для компиляции кода (поэтому и проблем с esm/cjs модулями нет). Но для меня это плюс, так как использую его только в дев режиме или для быстрого запуска какого-то скрипта. А если о чем-то забыл — то проверка в CI уже выручает.

В общем, всем советую попробовать)

https://tsx.is/

Давайте продолжим сегодня разрабатывать наше приложение для замера скорости печати. Кто может подключайтесь на стрим в 15:30 по мск.

В прошлый раз мы полностью доделали подсчет слов в коде и унифицировали логику между обычным текстом и кодом.

На данном стриме планирую:
- До конца разобраться с отображением текста. Сделать правильный перенос слов на маленьких экранах.
- Добавить каретку.
- Попробовать сделать скрипт, который бы парсил репозиторий и на его основе создавал заготовленные примеры кода для тестов.

Ну и как всегда буду отвечать на ваши вопросы в чате)

https://www.youtube.com/live/Qve3DgHnIYk

Начинаем!

[1/3]

Итоги года и дальнейшие планы

Обычно все пишут итоги под конец декабря, но я все откладывал, так как не было красивых цифр и больших достижений... Однако понял, что есть интересные моменты, которыми стоит поделиться. Да и для себя будет полезно закрепить результаты.

Если говорить про цифры:

- +1195 подписчиков, 148к просмотров на YouTube. Выпустил всего 3 видео и провел 6 стримов.
- 19 постов в телеграм, +78 подписчиков.

Тут, к сожалению, больше ничего и не добавить) Если не выпускать контент - то и роста понятное дело не будет. В этом плане кстати YouTube приятно удивил, все равно продолжает продвигать некоторые видео.

В плане дохода пока все также не смог перебить свой рекорд в найме.

Но тем ни менее нет ощущения того, что год прошел зря и я просто потерял время.

Если говорить про прогресс, то основной рост, я бы сказал, был в переосмыслении и смене взгляда на многие моменты. Большинство из этого, казалось бы, очевидно. Но пока сам на грабли не наступил - не понял)

Вот некоторые из них:

1. Наконец-то осознал то, что не стоит сидеть и пытаться разобраться во всем самому. Даже если все кажется просто и очевидно. Как минимум пообщавшись с человеком, который прошел подобный путь, вы сможете убедиться, что были правы. А скорее всего, как в моем случае, поймете, что ваше представление о реальности было совсем искаженным.

В этом году таких моментов было не мало. И тут еще повезло, что в какой-то момент находился человек в кругу общения, который мог бы дать нужный совет (всем причастным большое спасибо!).

Причем самое смешное, что многие проблемы, в которых я хотел разобраться сам и думал, что знаю, что нужно делать - в итоге сам и не решил. Просто в какой-то момент кто-то со стороны замечал, что я явно делаю что-то не то).

Для себя я на будущее понял, что вне зависимости от ситуации есть смысл потратить деньги и пообщаться с экспертом по теме. Касается это не только историй по типу развития карьеры и личного дела, но и более "житейских" случаев (тренировки, подбор рациона, совет при покупке чего-то дорогого и тд.).

А, ну и многие пункты ниже я тоже осознал не сам)))

[2/3]

2. Полностью поменялось отношение к работе и отдыху.

Дам небольшую предысторию. Где-то последний год было ощущение того, будто спадает эффективность. Работаю также, делаю меньше, тренируюсь менее интенсивно, сплю больше, чувствую себя хуже, желания что-то делать сильно меньше. Питание +/- по бжу сбалансировано, витамины всегда пил. Анализы сдал - там тоже все нормально.

И тут как раз в один момент времени мне сразу человека 3-4 сказали о том, что у меня перегруз. Как же так? Не так уж давно я делал сильно больше, спал меньше и чувствовал себя в разы лучше. По началу не хотелось даже брать в счет такую возможность. Но вариантов других особо и не было, поэтому решил полностью дать себе волю и отдыхать сколько захочется).

Первые полторы-две недели спал по 11-12 часов. Причем по несколько заходов. Ночью 9-10, днем еще 2-3 часа. Работал, может, где-то 2 часа, в зал тоже не ходил.

Затем с каждым днем количество часов сна уменьшалось. Самочувствие тоже становилось все лучше и лучше. Начало появляться желание поработать и приходить идеи для контента.

В какой-то момент начал сам просыпаться после 6-7 часов сна. Тогда уже начал потихоньку возвращать нагрузку. Сейчас вернулся на комфортный уровень. В зал хожу 2 раза, убрал все созвоны с выходных (кроме 1). А самое главное запомнил, какое состояние является нормой, а какое нет). И теперь понимаю разницу между тем, когда лень, а когда реально устал и надо отдохнуть.

Так вот, возвращаясь к нашей теме. Каким образом я дошел до такого состояния?

Основная проблема заключалась в том, что изначально режим и нагрузка были выстроены таким образом, что их нельзя было поддерживать долгое время. После ухода с работы почти каждые выходные работал, если не приходилось куда-то уезжать. Суббота стабильно была забита созвонами. В вс тоже часто что-то делал.

И если по началу это помогало реально делать больше, то со временем копилась усталость и падала продуктивность. И вместо того, что бы адекватно оценить ситуацию, я продолжал сидеть и заставлять себя работать. Думал, что просто лень. Вот же, буквально недавно сидел так же, и было все норм. Да и если копнуть глубже, то был страх того, что вот сейчас начну позволять себе отдыхать и потом вообще расслаблюсь и не смогу вернуться в колею)

Мотивации со временем становилось все меньше и меньше, приходилось все больше и больше себя заставлять что-то делать. Но почему-то я даже не задумывался о том, что надо что-то менять... В какой-то момент все дошло до того, что за весь день продуктивной работы было где-то час-два.

Благо в нужный момент сразу несколько людей обратило внимание. Иначе сам не знаю сколько еще так проходил бы...

Выводы из этой ситуации сделал такие, что установка "если нет мотивации - то надо себя заставлять" не особо полезна. Нужно смотреть на свое состояние в момент времени. Нет смысла выжимать из себя пару часов работы, чтобы потом на следующий день самочувствие было еще хуже. Ну и если пару дней поработать чуть меньше или вообще отдохнуть, то вряд ли из-за этого можно потерять всю дисциплину и стать лентяем)

[3/3]

3. Понял, что только на дисциплине далеко не уедешь.

Пару месяцев назад по совету одного из своих друзей решил обратиться к коучу по вопросам развития менторства. И в процессе ответов на интересно поставленные вопросы осознал, что у меня не совсем правильное отношение к дисциплине. И вместо того, чтобы искать реальную проблему я часто скидываю все на то, что надо взять себя в руки и идти дальше.

Вопрос в том, что да, дисциплина помогает вместо ютуба и сладостей выбрать работу и нормальное питание, помогает делать что-то, не сразу видя в этом результат. Да и даже если делать то, что вам реально нравится, будут те неприятные 20% работы, которых никак не избежать.

Но с другой стороны, если вам 100% времени приходится заставлять себя все делать и работать "из-под палки", то долго ли так можно продержаться? Хорошо подумав, я понял, что ни один такой "рывок воли" больше чем 6 месяцев у меня не длился)

Значит дело не только в дисциплине. Если вам постоянно что-то не хочется делать, стоит подумать почему. Возможно просто устали, возможно нет понимания для чего это нужно, а возможно просто нужно по другому взглянуть на ситуацию).

В моем случае я понял, что примитивное мышление "просто забей и делай" не особо показывает результаты...

4. Более просто стал относиться к контенту, и в целом понял, что нет ничего страшного, если в видео где-то что-то будет не идеально. Раньше перед выкладкой каждого ролика было волнение, вдруг там что-то не так сказал, вдруг ошибся, вдруг сам не так понял тему.

Но с другой стороны пришло осознание (тут коучинг тоже большую роль сыграл), что ни один человек, за которым я слежу долгое количество времени, не был "идеален". Да и в целом мне нравится послушать чье-то личное мнение из его опыта, нежели идеально поданную и не имеющую ни одной оговорки информацию.

Это не значит, что планирую понижать планку качества контента. Скорее просто меньше париться о вещах, которые не имеют значения для 99% аудитории. В худшем случае всегда можно исправить себя в комментариях или следующем ролике/посте.

———

Если посидеть и подумать, то думаю можно еще пару пунктов добавить, но думаю и так уже вышло сильно больше, чем я себе представлял)

В личном плане из успехов за прошлый год могу выделить такие моменты:

- Организовал себе рабочее место, на которым приятно работать. Пришлось много чего перепробовать, но оно точно того стоило.
- Смог пересесть на сплит клавиатуру. Долгое время откладывал это, пару месяцев назад собрался силами и ни разу не пожалел.
- Удалил все зубы мудрости (росли горизонтально). Лично у меня все прошло супер легко, первые 3 дня только есть было сложно.
- Наконец начал стабильно ходить в зал. А то после переезда из РФ 1.5 года занимался с переменным успехом.

Какие дальше планы?

В плане целей ничего не поменялось. Хочется дальше развивать ютуб/телеграмм каналы и менторство. Результаты 2024 года перебить, кажется, не должно быть так сложно.

По контенту есть много интересных идей. Хочу также продолжить регулярно проводить стримы. Пробовать на них делать интересные проекты на разных технологиях. Надеюсь в скором времени уже все увидите)

Ну и из самого главного, планирую в этом году сделать акцент не на большие цифры, а стабильность. Хочется выстроить график / процессы таким образом, чтобы можно было стабильно прогрессировать по каждому из аспектов жизни. Для себя я понял, что это работает намного лучше, чем "рывки воли" на 6-8 месяцев и потом спад продуктивности.

Друзья, кто может подключайтесь на стрим в 17:30 по мск (GMT+3). Продолжим разрабатывать приложение для замера скорости печати.

В прошлый раз закончили с визуалом — реализовали каретку, перенос слов на новую строку и отображение ошибок в пробелах / переносах строк.

В данном же стриме хотелось бы доделать следующие фичи:
- Скрипт для генерации тестов из репозитория
- Сбор статистики

Ну и на ваши вопросы в чате тоже буду отвечать.

https://www.youtube.com/live/hy1gzM0OdIs

Вчера на стриме столкнулся с проблемой, что вместо нодовоской типизации fetch’а подхватывалась браузерная. И из-за этого были TS ошибки при попытке записать стрим в файл.

const response = await fetch(...)

// ...

const fileStream = fs.createFileStream(fileName);

stream.Readable.fromWeb(response.body).pipe(fileStream);
//                      ^^^^^^^^^^^^^
// Argument of type 'ReadableStream<Uint8Array<ArrayBufferLike>>' 
// is not assignable to parameter of type 'ReadableStream<any>'.

Ошибка вылетает потому, что тип response.body в браузере имеет другой тип, нежели в node.js. Вчера решил особо с этим не сидеть, чтобы не тянуть время, поэтому просто поставил @ts-expect-error.

Но сегодня утром задумался, а откуда вообще берутся типы браузерные? В tsconfig стоит "types": ["node"], а свойство lib вообще не задекларировано.

Сначала грешил на vscode, но и при запуске через cli появлялась ошибка. Так вот, оказалось, что TS сам по дефолту добавляет некоторые типы (включая DOM), если не кастомизировать lib в конфиге.

TypeScript includes a default set of type definitions for built-in JS APIs (like Math), as well as type definitions for things found in browser environments (like document)

На выходе получаем то, что у нас подключена типизация как браузера, так и node.js. И тут уже как удача подвернется, у нас матчится одна из версий функции. В данном случае с fetch бралась не та версия, которая была нужна.

Фикс оказался довольно простой, добавил "lib": ["ESNext"] в tsconfig и типизация браузера больше не подключается.

Кстати, такая проблема часто с setTimeout тоже происходит. TS говорит, что timerId не number, а NodeJS.Timeout.

Если вы пишете серверное приложение, то ошибка по делу и стоит его послушать. Но если это клиентский код, то можно использовать window.setTimeout, тогда точно типизация будет браться правильная.

Готовил тут сheatsheet для собесов, хотел показать, как делается polyfill для Object.create. Казалось бы, все очевидно, сто раз такое делал)

function Empty() {}
function objectCreate(proto) {
    Empty.prototype = proto;
    const result = new Empty();
    Empty.prototype = null;
    return result;
}

Придирчивые скажут, что есть еще второй аргумент propertiesObject который описывает, какие свойства надо создать в самом объекте и какой у них будет property descriptor (работает аналогично Object.defineProperties).

Но, обычно им никто и не пользуется. Да и думаю большая часть тех, кто задает подобные вопросы на собесе вряд ли сами знают об этом аргументе. Поэтому данный момент можно упустить.

let test = objectCreate({a: 10});

console.log(test.a); // 10
console.log('a' in test); // true
console.log(test.hasOwnProperty('a')); // false
console.log(Object.getPrototypeOf(test)); // {a: 10}

Тесты выше показывают, что все работает так нам нужно. Но, давай проверим кейс Object.create(null):

let test = objectCreate(null);

console.log(Object.getPrototypeOf(test)); // {__defineGetter__: f, ...}
console.log(Object.getPrototypeOf(test) === Object.prototype); // true
console.log(Object.getPrototypeOf(test) === null); // false 

А такой кейс уже не работает...

Проблема заключается в том, что если у конструктора свойство prototype является null - то в прототип созданного объекта по дефолту подставится Object.prototype. То есть на выходе мы получим просто пустой объект {}.

При быстром поиске stack overflow, ChatGPT и github gist'ы все дают то же самое решение, что и у меня выше. Object.setPrototypeOf и __proto__ были добавлены в стандарты в ES5 вместе с Object.create, значит их использовать тоже нельзя для написания полифила.

Но я точно помню, что Object.create можно было полифилить, даже вроде на каком-то проекте пришлось добавлять для древних браузеров.

От безысходности решил посмотреть в core-js и увидел там очень интересный подход к решению проблемы (примеры кода ниже были упрощены для более простого чтения/понимания, оригинал содержит много деталей, которые не сильно важные в контексте данного поста).

// https://github.com/zloirock/core-js/blob/master/packages/core-js/internals/object-create.js#L75
var EmptyConstructor = function () { /* empty */ };

function create(O, Properties) {
  var result;
  if (O !== null) {
    EmptyConstructor.prototype = O;
    result = new EmptyConstructor();
    EmptyConstructor.prototype = null;
  } else result = NullProtoObject();
  return Properties === undefined ? result : definePropertiesModule.f(result, Properties);
};

Как можно увидеть, если в качестве прототипа передается null - то в таких кейсах используется отдельная функция NullPrototypeObject. И выглядит они следующим образом:

var enumBugKeys = [
  'constructor',
  'hasOwnProperty',
  'isPrototypeOf',
  'propertyIsEnumerable',
  'toLocaleString',
  'toString',
  'valueOf'
];

// Create object with fake `null` prototype: use iframe Object with cleared prototype
var NullProtoObjectViaIFrame = function () {
  var iframe = document.createElement('iframe');
  var iframeDocument;
  iframe.style.display = 'none';
  document.documentElement.appendChild(iframe);
  iframe.src = 'javascript:';
  iframeDocument = iframe.contentWindow.document;
  iframeDocument.open();
  iframeDocument.write('<script>document.F=Object</script>');
  iframeDocument.close();
  return iframeDocument.F;
};

var NullProtoObject = function () {
  NullProtoObject = NullProtoObjectViaIFrame()
  var length = enumBugKeys.length;
  while (length--) delete NullProtoObject.prototype[enumBugKeys[length]];
  return NullProtoObject();
};

По сути тут решается проблема того, что по дефолту в JS нет объекта с пустым прототипом. Самим его создать тоже не получается. Значит единственный вариант - это почистить прототип какого-то существующего объекта.

Так как все встроенные конструкторы (Array, Date, Function) и кастомные классы наследуются от Object, то их самих по себе отчистить нельзя. Придется и по цепочке вверх идти. Значит единственный вариант - это Object.

Однако у объекта тоже есть методы (`toString`, hasOwnProperty и тд), которые могут использоваться где-то в коде. Поэтому безопасно подчистить их не получится.

И тут как раз и приходит iframe, который внутри себя имеет отдельную среду со своим window, document и тд. Так как мы создаем iframe на той же странице, у нас есть доступ к его "кишкам" и мы можем спокойно доставать любые глобальные объекты из его window.

Выходит, что у нас появляется доступ к объекту Object из другой среды, в которой он точно использоваться не будет. Поэтому мы можем спокойно подчистить его прототип и использовать в качестве объекта с прототипом null.

Не думаю, что на собесе стоит писать такое решение и выдавать такие подробности. Но как минимум упомянуть, что дефолтное решение со stackoverflow не покрывает все кейсы лишним быть не должно.

Начал писать посты на канал, пошел стабильный рост подписчиков.

Рост правда отрицательный)))

Для тех, кто еще не видел, Create React App стал deprecated. Если кто-то до сих пор его использует — то пора остановиться)

https://react.dev/blog/2025/02/14/sunsetting-create-react-app

Часто получаю вопросы о том, что делать если нужно тестировать локальный фронт (на localhost) с API, которая находится в testing/staging/preprod/prod (или любая другая среда), где строго прописаны правила CORS и кук.

С CORS обычно проблем не бывает, вопросы с собесов уже давно всех научили тому, что это фича чисто браузерная, и при запросе через прокси-сервер все будет нормально.

Однако когда дело доходит до кук, которые выставляются бекендом, у всех почему-то возникают проблемы. Хотя никто нам не запрещает делать то же самое. Куки ведь точно также выставляются бекендом и отправляются туда с помощью хедеров Set-Cookie / Cookie.

Давайте сначала разберемся в том, в каких случаях сервер, развернутый на другом хосте не может выставлять куки:

1. Safari и Firefox вне зависимости от ситуации будут блочить куки с полностью разных доменов без общего "родителя". Например, front.asdf.com => api.asdf.com еще может работать, если правильно настроить. А вот кейс foo.com => asdf.com может работать только в Chrome (подробнее ниже).

2. Access-Control-Allow-Origin не содержит наш origin. Причем важная деталь заключается в том, что wildcard * тоже не будет работать. Браузер просто проигнорит такие куки.

3. Если браузер отправил запрос без настройки credentials: 'include' (или withCredentials: true, для XMLHttpRequest). В таком случае он не прикрепляет к cross-origin запросу куки и игнорирует Set-Cookie хедер, приходящий в response headers.

4. Access-Control-Allow-Credentials не выставлен в true. В таком случае сервер говорит о том, что он не принимает куки с других origin'ов. Ну и запросы с credentials: 'include' будут выкидывать ошибку по корсам.

5. Значение Domain выставляемое куке должно матчится с доменом, с которого мы делаем запрос (либо тот же домен, либо поддомен).

6. В случае с запросами с полностью разных доменов (foo.com => asdf.com) нужно выставить SameSite=None; Secure. Иначе куки будут проигнорованы. Еще раз напомню, что даже с правильным SameSite кейс будет работать только в Chrome.

Соответственно, чтобы нам избежать всех этих проблем при локальной разработке, достаточно просто развернуть прокси-сервер, ходить через него на бекенд и отправлять браузеру response со скорректированными хедерами, дабы избежать всех ограничений, описанных выше.

В Vite, например, для этого из коробки есть удобная настройка сервера server.proxy.

Для большинства кейсов вот такой конфиг закроет все нужды:

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      "/api": {
        // куда будет проксироваться запрос
        target: "https://some-backend.com",
        // переписывает host хедер на `target`
        changeOrigin: true,
        // убирает domain из `set-cookie` хедера.
        // можно прописать другой домен
        cookieDomainRewrite: "",
      },
    },
  },
});

В webpack то же самое можно сделать через devServer.proxy. Там под капотом та же библиотека (http-proxy) используется для проксирования запросов, поэтому конфиги будут очень похожи.

Если же вы используете Next.js или любой другой сетап, где нет конфигурации прокси из коробки, то всегда можно реализовать логику проксирования самому.

Примеры проксирования на Next.js через API Route можно найти по ссылке ниже (там же и пример с vite есть). А так на основе примера Next.js можно спокойно написать прокси-сервер на любом фреймворке либо воспользоваться уже существующим решением. Тут уже GPT в помощь)

https://github.com/Ayub-Begimkulov/server-cookies-proxy

Вчера вышла новость о том, что TS начали переписывать на Go. В планах к концу 2025 получить уже полностью рабочую версию с поддержкой всех фич.

Новость не может не радовать. Я думаю все, кто работали над кодовой базой с 400к+ строк кода знают, что type checking может работать не так быстро, как хотелось бы.

И если для процесса сборки это еще не настолько критично, так как там обычно используется babel или esbuild, которые игнорируют типы. А тайпчек делается в параллель или вообще отдельной задачей. То для перформанса в редакторе даже 1-2 секунды могут быть очень важны.

На текущий момент бенчмарки уже показывают улучшение перформанса в 10 раз. Понятное дело, что фичи пока не все поддержаны и в будущем эти цифры могут чуть поменяться. Но разница точно будет заметна)

https://devblogs.microsoft.com/typescript/typescript-native-port/

P.S. Также в комменты приложил ссылку на интервью с создателем TS, где он более детально рассказывает о решении использовать именно Go, дальнейших планах и отвечает на много других вопросов.

Недавно для себя открыл утилиту open в терминале мака (из того, что я понял, работает только на маке, в linux есть `xdg-open`), которая позволяет открыть файл используя дефолтную для него программу (тоже самое что и двойной клик по файлу в file explorer).

open ./index.html # открывает файл в дефолтном браузере
open http://google.com # открывает url в дефолтном браузере
open document.pdf # открывает документ в дефолтное приложении для pdf

Вроде мелочь, но бывает очень полезно. А то раньше часто приходилось отдельно открывать finder искать нужную директорию через CMD + Shift + G и руками открывать файл)