Я довольно много писал на С, и добрая половина строк кода там — обработка веток всевозможных ошибок — написание которых, это выброшенное на ветер время (а делать приходится).
А практически каждый мой код-ревью Сишного кода заключался в добавлении кучи проверок, которые многие (особенно начинающие) программеры забывают добавлять, тем самым приводя программу к непредсказуемому поведению в непредсказуемых местах (далеко от места ошибки).
Отлаживать и исправлять необработанные исключительные ситуации на порядок проще, чем необработанные коды ошибок.
так вроде проксировать SSH траффик (man in the middle) и раньше было можно… или я что-то недопонимаю?
мы ставили просто прокси в середине — клиент коннектился к нему, расшифровывали траффик и шифровали обратно, и отдавали настоящему серверу.
Наверное, просто стиль изложения неверно выбран — если переводить ситуации в серьезную форму, то они становится логичными и есть о чем подискутировать — об откатах, о конторах, которые непонятно чем занимаются и не понятно какие деньги и личности там крутятся, и т.п. Но выбранный стиль и выбранная ассоциация с булками… забавные, конечно, но ИМХО не очень удачные, поэтому и реакция в комментариях такая несколько однобокая, мне кажется.
Суперский активный угол очень полезен, когда через Remote Desktop пытаешься работать с окном терминала — попасть в активный пиксель угла абсолютно не реально.
Не только про AMD. Во времена расцвета 2-3-486 процессоров их не копировал только ленивый, и продавали под очень похожими названиями. Потом копировать продолжили, но продавать под похожими названиями стало значительно сложнее, и соответственно доказывать полную совместимость потребителю стало тоже намного сложнее.
Стоит еще упомянуть, что они поменяли цифровую кодировку на торговую марку Pentium, чтобы защитить свои процессора от копирования конкурентами под очень похожими номерами. И действительно, сильно ограничили таким образом конкуренцию (или просто огромными расходами на исследования, неподъемными для большинства конкурентов).
На днях буквально смотрел в очередной раз на ее лицензии, и посчитал, сможем-ли мы вписаться в 10 пользователей. При 4-6 активных разработчиках, 2 тестерах, и 2-4 манагеров, и нескольких сторонних товарищей, которым тоже нужно предоставить доступ хотя-бы для чтения — уже плохо вписываемся. Хотя, конечно, при таком раскладе должны быть деньги на нормальную лицензию… но пока экономим $100 в месяц и пользуемся Redmine.
Я отправил статью супруге — она сразу обратила внимание на пример страницы рассылки, приведенный в статье.
Тексты в этом примере очень безграмотные — вчитайтесь в описание игры «Монополия с банковскими картами», к примеру. Кроме простых грамматических ошибок, там и смысл предложений сложно уловить — кто ее захочет купить, с таким описанием? Две последних игры тоже описаны не ахти как. Очень похоже на результат не очень качественного перевода с английского.
Сама статья очень хороша, а вот модерированием текстов описаний игр стоит заняться :-)
При партицировании (разбиении?) таблиц в PostgreSQL нужно обращать внимание на довольно жесткое ограничение количества партиций (унаследованных таблиц? разделов?). На практике, количество таких партиций не должно быть более 50-100 (по рекомендациям вычитанным в Инете). Это связано с работой планировщика запросов, который перебирает все разделы, чтобы решить, к каким обращаться, и делает это линейно. И для 100+ партиций, по отзывам, он работает не эффективно, и тормозит запросы.
Также (хотя про это никто не пишет), меня одолевают сомнения, как файловая система будет работать с каталогом, содержащим файлы базы данных PostgreSQL (каждая база — один каталог, в котором каждый файл — это одна таблица или индекс), если мы создадим 1,000 партиций какой-нибудь таблицы скажем с 4мя индексами — 5 файлов на партицию = 5,000 файлов — это на одну такую супер-таблицу.
Я планировал сначала такое дело для нашей базы — разбить данные по месяцам и по клиентам, но количество разделов на 10 лет получается порядка 100,000-1,000,000 :-) так что я эту идею бросил, и начал думать в направлении раскладывать клиентов в разные схемы+тэйблспэйсы, а каждого из них в его тэйблспэйсе уже бить по годам — тогда количество разделов получается разумное.
Кроме ограничения по времени, с которым все более-менее согласны, статья очень спорная.
В данном случае, ИМХО:
1. Описание собеседования бессистемно — у собеседования должна быть определенная структура, и она очень важна, с временными рамками на каждый этап (если-уж мы время ограничиваем).
2. «не нужно спрашивать, кем человек был» — очень зря, при рассмотрении прошлых работ или проектов как раз очень много можно о человеке узнать — был-ли он вовлечен/заинтересован, интересовался-ли он проектом в целом и бизнес-целями организации, или тупо кодил свой модуль, умеет-ли он вообще внятно объяснить архитектуру и детали реализации того, чем занимался — а это все ключевые факторы успешного сотрудника.
3. под конец такое ощущение, что статья скомкана — писать надоело :-)
Нет особого смысла ограничивать — те, кто не справляются, отсеиваются автоматически на начальном этапе. А так, да, продвинутые курсы не помешают. Появятся со временем.
Я довольно много писал на С, и добрая половина строк кода там — обработка веток всевозможных ошибок — написание которых, это выброшенное на ветер время (а делать приходится).
А практически каждый мой код-ревью Сишного кода заключался в добавлении кучи проверок, которые многие (особенно начинающие) программеры забывают добавлять, тем самым приводя программу к непредсказуемому поведению в непредсказуемых местах (далеко от места ошибки).
Отлаживать и исправлять необработанные исключительные ситуации на порядок проще, чем необработанные коды ошибок.
мы ставили просто прокси в середине — клиент коннектился к нему, расшифровывали траффик и шифровали обратно, и отдавали настоящему серверу.
Потом начали добавлять ядра — тоже до упора…
Потом начали улучшать энергопотребление — дальше особо некуда…
Теперь улучшаем скорость переключения между спящим режимом и рабочим…
Следующий виток соревнования производителей процессоров — совершенствование кнопки Power!!!
В день или в год?
Тексты в этом примере очень безграмотные — вчитайтесь в описание игры «Монополия с банковскими картами», к примеру. Кроме простых грамматических ошибок, там и смысл предложений сложно уловить — кто ее захочет купить, с таким описанием? Две последних игры тоже описаны не ахти как. Очень похоже на результат не очень качественного перевода с английского.
Сама статья очень хороша, а вот модерированием текстов описаний игр стоит заняться :-)
Также (хотя про это никто не пишет), меня одолевают сомнения, как файловая система будет работать с каталогом, содержащим файлы базы данных PostgreSQL (каждая база — один каталог, в котором каждый файл — это одна таблица или индекс), если мы создадим 1,000 партиций какой-нибудь таблицы скажем с 4мя индексами — 5 файлов на партицию = 5,000 файлов — это на одну такую супер-таблицу.
Я планировал сначала такое дело для нашей базы — разбить данные по месяцам и по клиентам, но количество разделов на 10 лет получается порядка 100,000-1,000,000 :-) так что я эту идею бросил, и начал думать в направлении раскладывать клиентов в разные схемы+тэйблспэйсы, а каждого из них в его тэйблспэйсе уже бить по годам — тогда количество разделов получается разумное.
В данном случае, ИМХО:
1. Описание собеседования бессистемно — у собеседования должна быть определенная структура, и она очень важна, с временными рамками на каждый этап (если-уж мы время ограничиваем).
2. «не нужно спрашивать, кем человек был» — очень зря, при рассмотрении прошлых работ или проектов как раз очень много можно о человеке узнать — был-ли он вовлечен/заинтересован, интересовался-ли он проектом в целом и бизнес-целями организации, или тупо кодил свой модуль, умеет-ли он вообще внятно объяснить архитектуру и детали реализации того, чем занимался — а это все ключевые факторы успешного сотрудника.
3. под конец такое ощущение, что статья скомкана — писать надоело :-)