Не соглашусь. Даже версии стандартных утилит отличаются от дистрибутива к дистрибутиву (а так же у линукса и мака, например). Поэтому, на мой взгляд привычка использовать только стандартные - вещь тут лишняя. Но знание стандартных обязательно.
Честно говоря, такие требования уже хочется применять к любому сервису. Жаль это утопия, ибо без ограничений денег не поимеешь. Но надеюсь силами коммьюнити хотя бы софт будет таким.
Нет политике - это про политику ресурса, а не про обсуждение мировой политики. И не путайте культуру отмены с фильтром на информацию. Порнографию вы тут тоже не можете постить, отменяют ли вас таким образом?
Я не буду отвечать на часть про хейт, так как это политика.
Нельзя быть русскоязычным ресурсом и поливать грязью русских в том или ином виде.
Я вам даже больше скажу, нельзя поливать грязью любого человека по расовому признаку или из-за гражданства, которое оно имеет. Вне зависимости от языка ресурса.
Нельзя игнорировать текущую ситуацию в мире и замалчивать то, что происходит.
Я считаю, что в мире много ресурсов на множестве языков, в которых можно обсудить эту тему как с единомышленниками, так и с теми, кто с вами не согласен. Зачем техническому ресурсы быть таким? Я, как и, надеюсь, многие другие, хотели бы иметь уголки, где политика нас не настигнет. Ибо спрятаться от неё не так уж просто.
И не надо умывать руки - надо обсуждать.
Где-нибудь в другом месте, если со мной по итогу согласятся.
Ну после 24 февраля на пост-советском пространстве людей вне политики не осталось. А вот взгляды у всех разные, даже в пределах одной кровати.
Мой посыл в том, что для политсрачей есть много мест в интернете, хорошо бы иметь место и без них. И карма тут не спасает, так как количество ботов будет расти, как и количество политической инфы, а количество активных пользователей будет снижаться, как и количество полезной технической информации. Итог думаю понятен.
Я, отчасти, соглашусь с вами. Возможно часть новостей нужны, но именно в том ключе, какие от них последствия. Важно тут отделять полезную информацию от обсуждения, кто хороший, а кто плохой. Ну и думаю комментарии вряд ли нужны под такими постами.
Я и правда за жёсткую модерацию чувствительных топиков в неспокойное время. Возможно изначально был слишком радикален, и в каких-то случаях есть чуть более удачное решение, не меняющее суть идеи, которую я высказал, но улучшающее удобство её для пользователей.
И спасибо за комментарий, полезно было понять, где перегнул.
Я не буду говорить, на какой я стороне и есть ли сторона, на какой я. Минусы и плюсы я не ставлю и не могу.
Выражу мнение, что на этом ресурсе пора банить за любой политический комментарий и/или пост. Вне зависимости от стороны поддержки. Большинство пишет слишком однобоко, чтобы это было объективно.
В мире огромное количество ресурсов, где можно посраться на политические темы. Давайте здесь писать о технических вещах, а не о том, кому и что взбрело в голову и о том, как и кто относится к событиям, происходящим в мире.
Да, именно настолько жёстко, потому что иначе в нестабильной ситуации нельзя. Карма здесь не спасёт, лишь обеспечит отток людей, если хабр захватит сторона с тем или иным мнением. Раньше это более менее работало, потому что дисперсия не была такой огромной. К этому можно вернуться, когда всё стихнет.
TL;DR Тайминг статьи ужасен, для перехода на Линукс нужны более весомые причины.
Холиварные треды это весело, но главной причиной апдейта делать новые версии это конечно нонсенс. В 2010 мб это было острее, но в 2022 у винды есть WSL2, на маке работает почти всё, что на линуксе, а для остального есть докер. Исключения, думаю, есть, но для массового потребителя они нерелевантны.
Вин11, конечно, вызывает некоторые вопросы сейчас, но слишком рано оверреагировать. Для дружбы с линуксом, опять же, посоветую WSL2, а там жизнь покажет, насколько вам актуален переход.
Сеньор, который не пользуется опытом других, может конечно и сеньор, но обычно по ряду факторов (не по знаниям) в большей части компаний будет считаться плохим вариантом для найма.
Да запятые эт отдельная тема для холивара. Те же trailing запятые (не в SQL, но к примеру в js) кто-то любит, кто-то нет (я). Кто-то для избавления от trailing запятых начинает добавлять leading запятые, примерно как в посте (не я).
Тут и люди с отступами табами могут повозмущаться.
Идея вертикальной линии мне в целом нравится, если редактор или IDE будет уметь это делать автоматом. Если нет, можно и не заморачиваться на мой взгляд.
Я бы в первую очередь рассмотрел проектирование API в широком смысле, без привязке к какому-либо протоколу передачи данных, будь то http по tcp/ip или обычный вызов функции.
Если мы берём API с одной функцией, вы просто хотите взять набор данных X и получить в ответ набор данных Y или сведения об ошибке, а так же, возможно, добавить какой-то сайд эффект, например, модификацию данных.
В этом смысле условный User GetUser(int id) и GET /users/{id} решают одну и ту же задачу.
Далее у вас есть вполне очевидное требование, что consumer и provider это не части одной программы и даже не находятся на одной машине.
Поэтому вы выбираете последовательно протоколы на 4-7 уровнях OSI. Обычно всё сводится к TCP/IP и HTTP. И в этот самый момент, если у вас есть человек, отвечающий за архитектуру, стоит выбрать какой-то стандарт, который вы будете использовать. Вы можете остановиться на REST, добавить к нему JSON API, или же можете взять GraphQL. Возможно вам нужно своё решение. В редких случаях, стандарт трудно принять или практически невозможно, но частично стандартизировать что-либо можно, например способ именования параметров или ещё что-либо.
Далее, если выбранный стандарт имеет достаточно хорошие соглашения и у фронта есть понимание, что в апи не будет никаких подводных камней, то возможно, что фронт может сам предоставить спецификацию апи. К примеру, это хорошо работает для всяких простых CRUD эндпойнтов. Но в любом случае со стороны бэкэнда должна быть проверка этой спецификации. Так же хорошие соглашения позволят обнаруживать фронтэнду уже существующие эндпойнты, которые могут помочь им решить их задачу.
Если же бэкэнд достаточно сложный, то фронтэнд спректировать апи не может, и всё, что может сделать фронтэнд, это дать бэкэнд разработчикам input и ожидаемый output и попросить апи, которое им предоставят. Вот тут вероятно то, что концептуально выглядит как одна функция на фронтэнде, может превратиться в более чем один вызов функции (а в вашем случае в несколько HTTP запросов), либо, в целях оптимизации, в новый и сложный эндпойнт, который делает то, что вам нужно за один вызов. И вот тут, если вы используете достаточно хороший стандарт, спецификация может оказаться лучшим языком общения. А может и не быть им.
В общем случае, фронтэнд разработчик может предложить спецификацию АПИ как способ выразить свои требования по инпуту и аутпуту при хорошей стандартизации этого апи, но финальное слово за бэкэндом, ибо только они знают все ограничения бэкэнда и лучший путь реализовать требования фронтэнда.
Нужно ли для такой коллаборации специальное решение? Не уверен. Но и критиковать ваш проект я не готов.
На всякий случай предскажу его отсутствие. С теми же условиями доказавшему.
Downloaded. Когда ты смотришь файл на странице, ты по умолчанию его скачиваешь.
Не соглашусь. Даже версии стандартных утилит отличаются от дистрибутива к дистрибутиву (а так же у линукса и мака, например). Поэтому, на мой взгляд привычка использовать только стандартные - вещь тут лишняя. Но знание стандартных обязательно.
https://github.com/ibraheemdev/modern-unix ещё полезный список
Главный вопрос: а дальше его использовать тоже с VPN или можно без?
Честно говоря, такие требования уже хочется применять к любому сервису. Жаль это утопия, ибо без ограничений денег не поимеешь. Но надеюсь силами коммьюнити хотя бы софт будет таким.
По последнему опросу - хабрецы
Поддерживаю, дискриминация по цифровому признаку
Нет политике - это про политику ресурса, а не про обсуждение мировой политики. И не путайте культуру отмены с фильтром на информацию. Порнографию вы тут тоже не можете постить, отменяют ли вас таким образом?
Я не буду отвечать на часть про хейт, так как это политика.
Я вам даже больше скажу, нельзя поливать грязью любого человека по расовому признаку или из-за гражданства, которое оно имеет. Вне зависимости от языка ресурса.
Я считаю, что в мире много ресурсов на множестве языков, в которых можно обсудить эту тему как с единомышленниками, так и с теми, кто с вами не согласен. Зачем техническому ресурсы быть таким? Я, как и, надеюсь, многие другие, хотели бы иметь уголки, где политика нас не настигнет. Ибо спрятаться от неё не так уж просто.
Где-нибудь в другом месте, если со мной по итогу согласятся.
Ну после 24 февраля на пост-советском пространстве людей вне политики не осталось. А вот взгляды у всех разные, даже в пределах одной кровати.
Мой посыл в том, что для политсрачей есть много мест в интернете, хорошо бы иметь место и без них. И карма тут не спасает, так как количество ботов будет расти, как и количество политической инфы, а количество активных пользователей будет снижаться, как и количество полезной технической информации. Итог думаю понятен.
Я, отчасти, соглашусь с вами. Возможно часть новостей нужны, но именно в том ключе, какие от них последствия. Важно тут отделять полезную информацию от обсуждения, кто хороший, а кто плохой. Ну и думаю комментарии вряд ли нужны под такими постами.
Я и правда за жёсткую модерацию чувствительных топиков в неспокойное время. Возможно изначально был слишком радикален, и в каких-то случаях есть чуть более удачное решение, не меняющее суть идеи, которую я высказал, но улучшающее удобство её для пользователей.
И спасибо за комментарий, полезно было понять, где перегнул.
Я не буду говорить, на какой я стороне и есть ли сторона, на какой я. Минусы и плюсы я не ставлю и не могу.
Выражу мнение, что на этом ресурсе пора банить за любой политический комментарий и/или пост. Вне зависимости от стороны поддержки. Большинство пишет слишком однобоко, чтобы это было объективно.
В мире огромное количество ресурсов, где можно посраться на политические темы. Давайте здесь писать о технических вещах, а не о том, кому и что взбрело в голову и о том, как и кто относится к событиям, происходящим в мире.
Да, именно настолько жёстко, потому что иначе в нестабильной ситуации нельзя. Карма здесь не спасёт, лишь обеспечит отток людей, если хабр захватит сторона с тем или иным мнением. Раньше это более менее работало, потому что дисперсия не была такой огромной. К этому можно вернуться, когда всё стихнет.
TL;DR Тайминг статьи ужасен, для перехода на Линукс нужны более весомые причины.
Холиварные треды это весело, но главной причиной апдейта делать новые версии это конечно нонсенс. В 2010 мб это было острее, но в 2022 у винды есть WSL2, на маке работает почти всё, что на линуксе, а для остального есть докер. Исключения, думаю, есть, но для массового потребителя они нерелевантны.
Вин11, конечно, вызывает некоторые вопросы сейчас, но слишком рано оверреагировать. Для дружбы с линуксом, опять же, посоветую WSL2, а там жизнь покажет, насколько вам актуален переход.
Битва за инсту
Сеньор, который не пользуется опытом других, может конечно и сеньор, но обычно по ряду факторов (не по знаниям) в большей части компаний будет считаться плохим вариантом для найма.
Я как-то такую форму (had forgave) в песне услышал, очень удивился.
Да запятые эт отдельная тема для холивара. Те же trailing запятые (не в SQL, но к примеру в js) кто-то любит, кто-то нет (я). Кто-то для избавления от trailing запятых начинает добавлять leading запятые, примерно как в посте (не я).
Тут и люди с отступами табами могут повозмущаться.
Идея вертикальной линии мне в целом нравится, если редактор или IDE будет уметь это делать автоматом. Если нет, можно и не заморачиваться на мой взгляд.
Туркменистан вроде не лучше, если говорить об аналогах. Но могу и ошибаться, ибо глубоко не вникал. По остальной части с вами согласен.
Я бы в первую очередь рассмотрел проектирование API в широком смысле, без привязке к какому-либо протоколу передачи данных, будь то http по tcp/ip или обычный вызов функции.
Если мы берём API с одной функцией, вы просто хотите взять набор данных X и получить в ответ набор данных Y или сведения об ошибке, а так же, возможно, добавить какой-то сайд эффект, например, модификацию данных.
В этом смысле условный User GetUser(int id) и GET /users/{id} решают одну и ту же задачу.
Далее у вас есть вполне очевидное требование, что consumer и provider это не части одной программы и даже не находятся на одной машине.
Поэтому вы выбираете последовательно протоколы на 4-7 уровнях OSI. Обычно всё сводится к TCP/IP и HTTP. И в этот самый момент, если у вас есть человек, отвечающий за архитектуру, стоит выбрать какой-то стандарт, который вы будете использовать. Вы можете остановиться на REST, добавить к нему JSON API, или же можете взять GraphQL. Возможно вам нужно своё решение. В редких случаях, стандарт трудно принять или практически невозможно, но частично стандартизировать что-либо можно, например способ именования параметров или ещё что-либо.
Далее, если выбранный стандарт имеет достаточно хорошие соглашения и у фронта есть понимание, что в апи не будет никаких подводных камней, то возможно, что фронт может сам предоставить спецификацию апи. К примеру, это хорошо работает для всяких простых CRUD эндпойнтов. Но в любом случае со стороны бэкэнда должна быть проверка этой спецификации. Так же хорошие соглашения позволят обнаруживать фронтэнду уже существующие эндпойнты, которые могут помочь им решить их задачу.
Если же бэкэнд достаточно сложный, то фронтэнд спректировать апи не может, и всё, что может сделать фронтэнд, это дать бэкэнд разработчикам input и ожидаемый output и попросить апи, которое им предоставят. Вот тут вероятно то, что концептуально выглядит как одна функция на фронтэнде, может превратиться в более чем один вызов функции (а в вашем случае в несколько HTTP запросов), либо, в целях оптимизации, в новый и сложный эндпойнт, который делает то, что вам нужно за один вызов. И вот тут, если вы используете достаточно хороший стандарт, спецификация может оказаться лучшим языком общения. А может и не быть им.
В общем случае, фронтэнд разработчик может предложить спецификацию АПИ как способ выразить свои требования по инпуту и аутпуту при хорошей стандартизации этого апи, но финальное слово за бэкэндом, ибо только они знают все ограничения бэкэнда и лучший путь реализовать требования фронтэнда.
Нужно ли для такой коллаборации специальное решение? Не уверен. Но и критиковать ваш проект я не готов.
Worst of the best думаю можно сказать
It was the worst of the best options.