Бывает, что приходит продолжительный "тупняк". Долгое время не можешь связать даже двух слов в "коде", документации, отчетах. Действует угнетающе. Не знаю как у других, у меня такое изредка случается, вот как сейчас.
Иногда срочное задание может помочь выйти из ступора, иногда помогает попадание в ситуацию, когда идет выброс адреналина. В некоторых случаях можно приложиться к алкоголю. Но гарантированно прекратить творческий упадок, почти всегда, помогает физический труд: монотонный и продолжительный, или кратковременный, но очень интенсивный и тяжелый. Практика показывает, что вдохновение начинает потихоньку возвращаться уже после четвертой тонны перекиданного угля или щебня. :)
Буду воевать!
суббота, 26 июня 2010 г.
У меня дар использовать вещи не по назначению
Одна из таких вещей, блог. Я превратил инструмент, созданный для записи и публикации мыслей, в инструмент своих интенсивных размышлений. Произошло это благодаря механизму самого инструмента: можно записать новую мысль, отложить текущую в недописанное, опубликовать готовое.
Количество моих "черновиков" растет. Начав о чем-нибудь писать, замечаешь за собой нечеткость и противоречивость суждений, неосведомленность в деталях. Текст переписывается, уточняется, обдумывается, переписывается, обдумывается, переписывается еще раз. Уточняются детали. Переосмысливаются, уточняются, выбрасываются или заменяются другими тезисы. Если мнение на нетривиальную тему, мысль, о которой раньше не задумывался, то ты ее обдумываешь, вырабатываешь к ней свое отношение, стараешься четко его выразить. В итоге мнение может поменяться на противоположное. Бывает, если хорошенько задумываешься.
Но результаты не публикую. Могу удалить, но не публикую. Потенциально каждый может быть опубликован, только кнопку нажми, но это и сдерживает: вздор публиковать не хочется. Такое ощущение главный признак плохого владения вопросом. А после, когда прошло достаточно времени, и "пост" готов, то понимаешь, что незачем его публиковать. :)
Вспомнилась любимая поговорка (одна из ее вариантов): "если в чем-то хочешь разобраться, объясни это другому". Чувство удовлетворения испытывается не из-за хорошего поста, а от того, что разобрался в интересующем вопросе. Роль слушателя исполняет потенциальная "аудитория", даже если никто тебя не читает. Кнопка "Publish post" выполняет роль успешного завершения дела: нажать ее не стыдно, когда в нужной степени разобрался с вопросом. Но так-как другим это может быть не интересно, а я все "лулзы" уже получил, кнопку нажимать не обязательно. :)
Плохо то, что текст "льется" сам собой. Не приобрел желанную привычку составлять план, делать набросок, уточнять, корректировать. Изначально пишешь каждую строку как законченную вещь. С пунктуацией проблемы. Ну да ничего, это решаемо.
Количество моих "черновиков" растет. Начав о чем-нибудь писать, замечаешь за собой нечеткость и противоречивость суждений, неосведомленность в деталях. Текст переписывается, уточняется, обдумывается, переписывается, обдумывается, переписывается еще раз. Уточняются детали. Переосмысливаются, уточняются, выбрасываются или заменяются другими тезисы. Если мнение на нетривиальную тему, мысль, о которой раньше не задумывался, то ты ее обдумываешь, вырабатываешь к ней свое отношение, стараешься четко его выразить. В итоге мнение может поменяться на противоположное. Бывает, если хорошенько задумываешься.
Но результаты не публикую. Могу удалить, но не публикую. Потенциально каждый может быть опубликован, только кнопку нажми, но это и сдерживает: вздор публиковать не хочется. Такое ощущение главный признак плохого владения вопросом. А после, когда прошло достаточно времени, и "пост" готов, то понимаешь, что незачем его публиковать. :)
Вспомнилась любимая поговорка (одна из ее вариантов): "если в чем-то хочешь разобраться, объясни это другому". Чувство удовлетворения испытывается не из-за хорошего поста, а от того, что разобрался в интересующем вопросе. Роль слушателя исполняет потенциальная "аудитория", даже если никто тебя не читает. Кнопка "Publish post" выполняет роль успешного завершения дела: нажать ее не стыдно, когда в нужной степени разобрался с вопросом. Но так-как другим это может быть не интересно, а я все "лулзы" уже получил, кнопку нажимать не обязательно. :)
Плохо то, что текст "льется" сам собой. Не приобрел желанную привычку составлять план, делать набросок, уточнять, корректировать. Изначально пишешь каждую строку как законченную вещь. С пунктуацией проблемы. Ну да ничего, это решаемо.
пятница, 25 июня 2010 г.
Плохие привычки
Работа на дому усугубляет некоторые нюансы, встречающиеся на "нормальных" работах.
Чтобы их избежать, есть два совета.
1. Не советую смешивать рабочее и не рабочее время. Это две разных вещи, и их всегда следует разделять. Не скажу, что у меня это часто получается.
2. Не следует увеличивать время непрерывной работы. Это частично относится и к предыдущему пункту -- смешиваешь рабочее время и "отдых" за компьютером, увеличивается время непрерывного нахождения за ним. Время "чистой" работы тоже не желательно увеличивать. Умейте откладывать тревожащие мысли, проблемы и идеи: записывайте и планируйте, и смело плюйте в глаза тому, кто говорит что это лишняя трата времени.
Если запустить оба пункта, то они обязательно скажутся на здоровье, семейных отношениях, да и на самой работе, самым негативным образом. Может быть не сразу, но это еще хуже -- усыпляет бдительность и позволяет привиться плохим привычкам.
Чтобы их избежать, есть два совета.
1. Не советую смешивать рабочее и не рабочее время. Это две разных вещи, и их всегда следует разделять. Не скажу, что у меня это часто получается.
2. Не следует увеличивать время непрерывной работы. Это частично относится и к предыдущему пункту -- смешиваешь рабочее время и "отдых" за компьютером, увеличивается время непрерывного нахождения за ним. Время "чистой" работы тоже не желательно увеличивать. Умейте откладывать тревожащие мысли, проблемы и идеи: записывайте и планируйте, и смело плюйте в глаза тому, кто говорит что это лишняя трата времени.
Если запустить оба пункта, то они обязательно скажутся на здоровье, семейных отношениях, да и на самой работе, самым негативным образом. Может быть не сразу, но это еще хуже -- усыпляет бдительность и позволяет привиться плохим привычкам.
Никому не верь
Никому не верь. Да, вообще никому. Даже себе.
Не верь росказням. И не только потому, что они могут быть лживы и недостоверны, а потому что они могут не подойти. Товарищ рассказывал о мелких советах известного гуру из большой конторы, в плане оптимизаций. Всегда проверяй такие советы. Никогда не полагайся на авторитет. У тебя машина с совсем другими характеристиками, другая версия компилятора, другое програмное окружение. Даже если они схожи, эффект может быть разным. То, что совет может работать, но твоя система не получит от этого ни шиша, само-собой, всегда нужно учитывать. Но это я не о вреде преждевременной оптимизации, оптимизация -- просто пример.
Всегда полностью проверяй то, что намерен использовать, и именно в тех условиях, в которых намерен. Если проверил лишь часть, которая оказалась правдивой, то это еще не значит, будто остальное можно автоматически счить достоверным.
От баек, россказней, советов, статистики, статей и прочего можно отталкиватсья, нужно их проверять, нужно их критически оценивать (стоит вообще проверять, или нет). Но никогда не следует слепо верить тому, что говорят или пишут, даже авторитеты. Особенно авторитеты!
Условия разные (технические и организационные), акценты разные, приоритеты разные, и в конце-концов, твое понимание, восприятие и даже умение -- отличаются от того, что есть у рассказчика. Нужно запомнить, что советы подстраиваются "под себя", и не пытаться тупо скопировать чужую ситуацию. Внешнее сходство обманчиво. Может даже правильно проверить не получится, но пытаться нужно. Нужно учиться проверять и оценивать, только на ошибках учаться.
Не верь росказням. И не только потому, что они могут быть лживы и недостоверны, а потому что они могут не подойти. Товарищ рассказывал о мелких советах известного гуру из большой конторы, в плане оптимизаций. Всегда проверяй такие советы. Никогда не полагайся на авторитет. У тебя машина с совсем другими характеристиками, другая версия компилятора, другое програмное окружение. Даже если они схожи, эффект может быть разным. То, что совет может работать, но твоя система не получит от этого ни шиша, само-собой, всегда нужно учитывать. Но это я не о вреде преждевременной оптимизации, оптимизация -- просто пример.
Всегда полностью проверяй то, что намерен использовать, и именно в тех условиях, в которых намерен. Если проверил лишь часть, которая оказалась правдивой, то это еще не значит, будто остальное можно автоматически счить достоверным.
От баек, россказней, советов, статистики, статей и прочего можно отталкиватсья, нужно их проверять, нужно их критически оценивать (стоит вообще проверять, или нет). Но никогда не следует слепо верить тому, что говорят или пишут, даже авторитеты. Особенно авторитеты!
Условия разные (технические и организационные), акценты разные, приоритеты разные, и в конце-концов, твое понимание, восприятие и даже умение -- отличаются от того, что есть у рассказчика. Нужно запомнить, что советы подстраиваются "под себя", и не пытаться тупо скопировать чужую ситуацию. Внешнее сходство обманчиво. Может даже правильно проверить не получится, но пытаться нужно. Нужно учиться проверять и оценивать, только на ошибках учаться.
И так сойдет
Позвонил в сервисный центр по поводу солнцебоязни PocketBook, насчет возможности устранения недостатка. Сообщили, что сервис PocketBook отказывает в гарантийной замене по этому поводу, поскольку эффект проявляется при нарушении условий эксплуатации.
Вообщем-то, как я уже говорил, не особо критично. В тени перелистывание страницы восстанавливает номальную четкость экрана, и с этим вполне можно жить.
Вообщем-то, как я уже говорил, не особо критично. В тени перелистывание страницы восстанавливает номальную четкость экрана, и с этим вполне можно жить.
четверг, 24 июня 2010 г.
PocketBook: читайте документацию внимательно
Выяснилось, что баг с обновлением изображения на экране не пропал. Перелистываешь страницу, а буквы и элементы управления местами блеклые, не четкие, плохо прорисованные.
Локализовал ошибку случайно. Подметил, что проблема перерисовки возникает при попадании солнечных лучей. Чем ярче, тем больше эффект. Ехал в автобусе, читал книжку, и когда автобус поворачивал солнце попало на меня и гаджет, в это время "переворачивал" страницу... и достиг просветления. :) Поигрался -- эффект повторяемый. Показываешь солнышко экрану гаджета, листаешь, и пожалуйста, изображение портится.
В разделе о мерах предосторожности, руководства пользователя, упомянуто первым пунктом: "Не подвергать устройство воздействию прямых солнечных лучей". Встал вопрос, что такое "воздействие"? За пару секунд "засветил", пять минут подержал, на час забыл? Что такое прямые солнечные лучи? Просто попадание света на экран, или попадание под прямым углом? Завтра детали уточню.
Оказывается этот вопрос уже неоднократно поднимался на форуме www.the-ebook.org, причем еще год назад. То ли бракованая партия экранов была использована, то ли еще у определенных моделей такие особенности, толком не ясно. Разобравшись с поставщиком железа, лица, похожие на сотрудников PocketBook порекомендовали нести читалки в сервис, где их заменят или починят.
Не знаю, какое отношение к этой особенности у сервисных центров сейчас. Скажут "соблюдать условия эксплуатации", или заменят, починят... . Буду надеятся, что за год уж точно найдено решение проблемы, приятное для пользователя. Которое не требует мчаться в тень с быстротой опоздывающего вампира: ведь я так и не уяснил, вредны ли краткомоментные "выходы в свет" для устройства, т.е. не ухудшает ли это, со временем, его свойств.
Важность устранения эфекта зависит и от ситуаций его проявления. С этим нужно будет поэксперементировать. Возможно, что текущее положение дел меня вполне устроит.
Локализовал ошибку случайно. Подметил, что проблема перерисовки возникает при попадании солнечных лучей. Чем ярче, тем больше эффект. Ехал в автобусе, читал книжку, и когда автобус поворачивал солнце попало на меня и гаджет, в это время "переворачивал" страницу... и достиг просветления. :) Поигрался -- эффект повторяемый. Показываешь солнышко экрану гаджета, листаешь, и пожалуйста, изображение портится.
В разделе о мерах предосторожности, руководства пользователя, упомянуто первым пунктом: "Не подвергать устройство воздействию прямых солнечных лучей". Встал вопрос, что такое "воздействие"? За пару секунд "засветил", пять минут подержал, на час забыл? Что такое прямые солнечные лучи? Просто попадание света на экран, или попадание под прямым углом? Завтра детали уточню.
Оказывается этот вопрос уже неоднократно поднимался на форуме www.the-ebook.org, причем еще год назад. То ли бракованая партия экранов была использована, то ли еще у определенных моделей такие особенности, толком не ясно. Разобравшись с поставщиком железа, лица, похожие на сотрудников PocketBook порекомендовали нести читалки в сервис, где их заменят или починят.
Не знаю, какое отношение к этой особенности у сервисных центров сейчас. Скажут "соблюдать условия эксплуатации", или заменят, починят... . Буду надеятся, что за год уж точно найдено решение проблемы, приятное для пользователя. Которое не требует мчаться в тень с быстротой опоздывающего вампира: ведь я так и не уяснил, вредны ли краткомоментные "выходы в свет" для устройства, т.е. не ухудшает ли это, со временем, его свойств.
Важность устранения эфекта зависит и от ситуаций его проявления. С этим нужно будет поэксперементировать. Возможно, что текущее положение дел меня вполне устроит.
Графы, графини и графинчики
Ну вот, и эту секцию книжек тоже отсортировал и прошерстил на предмет дубликатов: Отечественные и переводы отдельно от зарубежных изданий
среда, 23 июня 2010 г.
Автоматы-автоматы, а я маленький такой
Наткнулся на пост jdevelop Мыслеформы, где заметил жж-пользователя realurix.
Нравится, когда человек ратует за четкость и однозначность терминов. Хоть ясно, что контекст и исторически сложившееся положение определяет значение слова. И от этого не уйдешь.
Товарищ тонко троллит. Обратил внимание на его попытки везде влезть с автоматами. Что в своем журнале, что у jdevelop. Комментарии у обоих мне не доступны, а хотелось уточнить пару вещей. К счастью "троллинг" вовремя распознал и не потратил время зря.
Например, интересно было, что он имеет ввиду под автоматами. Конечные автоматы? Помнится, где-то упоминалось об эквивалентности грамматик регулярных языков и детерминированных автоматов. Но слово "конечные" не упоминалось.
Услышав о сравнении детерминированных автоматов и лямбда-исчисления захотелось дать пример умножения двоичных чисел (Ю.Г.Карпов, "Теория автоматов", гл. 3, "Проблема умножения: алгоритм, которые не может выполнить КА"). Но тут склероз отступил; вовремя вспомнил, что автоматы бывают не только конечные, но еще и автоматы с магазинной памятью, клеточные автоматы, Машина Тьюринга, которая есть расширение конечного автомата. Так что в лужу сесть не довелось. Ну ничего, повод в будущем всегда представится. ;)
Вспомнил, что забросил обновлять списочек, и вообще забил на идею выкладывать на торрент свою библиотечку. Так что надо будет выложить из раздела Discrete Math/Automata Theory все немногое, что там лежит.
Нравится, когда человек ратует за четкость и однозначность терминов. Хоть ясно, что контекст и исторически сложившееся положение определяет значение слова. И от этого не уйдешь.
Товарищ тонко троллит. Обратил внимание на его попытки везде влезть с автоматами. Что в своем журнале, что у jdevelop. Комментарии у обоих мне не доступны, а хотелось уточнить пару вещей. К счастью "троллинг" вовремя распознал и не потратил время зря.
Например, интересно было, что он имеет ввиду под автоматами. Конечные автоматы? Помнится, где-то упоминалось об эквивалентности грамматик регулярных языков и детерминированных автоматов. Но слово "конечные" не упоминалось.
Услышав о сравнении детерминированных автоматов и лямбда-исчисления захотелось дать пример умножения двоичных чисел (Ю.Г.Карпов, "Теория автоматов", гл. 3, "Проблема умножения: алгоритм, которые не может выполнить КА"). Но тут склероз отступил; вовремя вспомнил, что автоматы бывают не только конечные, но еще и автоматы с магазинной памятью, клеточные автоматы, Машина Тьюринга, которая есть расширение конечного автомата. Так что в лужу сесть не довелось. Ну ничего, повод в будущем всегда представится. ;)
Вспомнил, что забросил обновлять списочек, и вообще забил на идею выкладывать на торрент свою библиотечку. Так что надо будет выложить из раздела Discrete Math/Automata Theory все немногое, что там лежит.
среда, 16 июня 2010 г.
Отношения на одну ночь
Xmonad -- звучит как имя французской проститутки.
Остаюсь на StumpWM, хоть после обновления и показалось, что подтомаживать стало чуть побольше, чем нужно. Для интереса собрал Xmonad, потрахался c виртальными окнами при использовании Xinerama/XRandr, заплатил и ушел.
updated
Остаюсь на StumpWM, хоть после обновления и показалось, что подтомаживать стало чуть побольше, чем нужно. Для интереса собрал Xmonad, потрахался c виртальными окнами при использовании Xinerama/XRandr
updated
вторник, 15 июня 2010 г.
Scala and Windows
Пользователям Windows, которые хотят использовать scala с NetBeans: scala-проекты нужно создавать в каталогах без пробелов (drive:\stuff\scala_projects\).
понедельник, 14 июня 2010 г.
PocketBook: новые версии, новые баги
Обновил прошивку в своем PocketBook (15.2).
Пропал баг с обновлением экрана. Вздохнул с облегчением.
Собственно, мне даже стало казаться, что я умудрился этот гаджет где-то уронить. Отсюда на экране при листании появлялись размытые места. Например половина экрана четкая, а на второй часть текста и интерфейса отрисованы так, будто на бумаге печатал принтер, у которого заканчивается тоннер. Иногда это явление портило весь экран. Перелистывание, на другую страницу и назад, меняло картину, но "портилась" следующая картинка, иногда через несколько страниц.
Видимо разбираться нужно было бы серьезно, поэтому откладывал, времени не было.
Ну да и хорошо, что хорошо кончается.
Последнее время заметил один баг у AdobeViewer. Возникает во время чтения pdf-файлов, при указании масштаба "по ширине", или указать его вручную.
Доходим до конца страницы, нажимаем "вниз", перескакиваем на следующую.
Возвращаемся назад (жмем "вверх") -- часть текста предыдущей страницы (в ее низу), не видна -- белый лист. Верхняя часть страницы, если поднятся выше, видна. Будто бы обрезали.
Кроме того, у AdobeViewer появился новый баг. Просмотр pdf-документа при масштабе "Компоновка" возможен только вперед. Кнопка "назад" перелистывает документ не на предыдущую, а на следующую страницу.
Чуть больше радует pdfviewer. Хотя в режиме компоновка он по прежнему не показывает некоторые pdf-файлы, например журнал fprog, зато упомянутые баги AdoveViewer его не коснулись.
На сегодня имеем два pdf-просмотрщика: один работает хреново, второй -- еще хреновее. Злорадно отмечу, что хреновее работает проприетарное решение. Но вцелом пользоваться устройством пока можно. Был бы доступен только один просмотрщик, было бы значительно хуже.
Надо будет send-pr сделать, если не забуду.
Пропал баг с обновлением экрана. Вздохнул с облегчением.
Собственно, мне даже стало казаться, что я умудрился этот гаджет где-то уронить. Отсюда на экране при листании появлялись размытые места. Например половина экрана четкая, а на второй часть текста и интерфейса отрисованы так, будто на бумаге печатал принтер, у которого заканчивается тоннер. Иногда это явление портило весь экран. Перелистывание, на другую страницу и назад, меняло картину, но "портилась" следующая картинка, иногда через несколько страниц.
Видимо разбираться нужно было бы серьезно, поэтому откладывал, времени не было.
Ну да и хорошо, что хорошо кончается.
Последнее время заметил один баг у AdobeViewer. Возникает во время чтения pdf-файлов, при указании масштаба "по ширине", или указать его вручную.
Доходим до конца страницы, нажимаем "вниз", перескакиваем на следующую.
Возвращаемся назад (жмем "вверх") -- часть текста предыдущей страницы (в ее низу), не видна -- белый лист. Верхняя часть страницы, если поднятся выше, видна. Будто бы обрезали.
Кроме того, у AdobeViewer появился новый баг. Просмотр pdf-документа при масштабе "Компоновка" возможен только вперед. Кнопка "назад" перелистывает документ не на предыдущую, а на следующую страницу.
Чуть больше радует pdfviewer. Хотя в режиме компоновка он по прежнему не показывает некоторые pdf-файлы, например журнал fprog, зато упомянутые баги AdoveViewer его не коснулись.
На сегодня имеем два pdf-просмотрщика: один работает хреново, второй -- еще хреновее. Злорадно отмечу, что хреновее работает проприетарное решение. Но вцелом пользоваться устройством пока можно. Был бы доступен только один просмотрщик, было бы значительно хуже.
Надо будет send-pr сделать, если не забуду.
пятница, 11 июня 2010 г.
Синтаксический сахар
Java -- трехлитровая банка с водой.
Python -- двухлитровая банка со сладким компотом.
Haskell -- пачка сахара-рафинада. Если кому сильно сладко, или беззубый, а кусочки дерут горло, запивают чем могут.
Scala -- банка Python, в которую впихнули и утрамбовали много пачек сахара-рафинада.
Lisp -- дольки сладких сухофруктов, которыми выкладывают магические узоры на тарелке. С виду невзрачные, но если уж кто подсел, то надолго.
Clojure -- компот из сухофруктов.
Эрланг -- банка с кучей мелких драже.
C# и F# -- леденцы, которые разрешают только сосать.
Теперь понимаю природу вечных стычек Лисперов с Хаскелитами. Редко кто может заедать сухофрукты рафинадом. Знаю одного, но он запивает рафинад компотом из сухофруктов.
Python -- двухлитровая банка со сладким компотом.
Haskell -- пачка сахара-рафинада. Если кому сильно сладко, или беззубый, а кусочки дерут горло, запивают чем могут.
Scala -- банка Python, в которую впихнули и утрамбовали много пачек сахара-рафинада.
Lisp -- дольки сладких сухофруктов, которыми выкладывают магические узоры на тарелке. С виду невзрачные, но если уж кто подсел, то надолго.
Clojure -- компот из сухофруктов.
Эрланг -- банка с кучей мелких драже.
C# и F# -- леденцы, которые разрешают только сосать.
Теперь понимаю природу вечных стычек Лисперов с Хаскелитами. Редко кто может заедать сухофрукты рафинадом. Знаю одного, но он запивает рафинад компотом из сухофруктов.
Не забываем о ресурсах
Готовый тестовый пример на Scala, c тредами. Создается 2000 тредов, которые делают что-то необременительное. Запускаю -- "java.lang.OutOfMemoryError: unable to create new native thread". Чудненько. Пляски вокруг параметров виртуальной машины не помогают, или наборот -- загоняют jvm в "корку".
Читаю документацию, ссылки, маны, пробую, комбинирую... температура (у меня и у проца) выросла еще на четыре градусов. Замечаю нюанс: ulimit во freebsd не показывает ограничения на кол-во тредов. В мане (bash) ключ "-T" есть, а в самой утилите -- нет. В линуксе, кстати, man правильнее, ключ там не указан.
И тут наступает прозрение.
Меняю на max_threads_per_proc до 2000, и сразу все как по маслу.
Никогда програмисты сами не научатся создавать сообщения об ошибках, точно отражающие ситуацию, если их жестоко не пинать. По себе знаю. :(
Читаю документацию, ссылки, маны, пробую, комбинирую... температура (у меня и у проца) выросла еще на четыре градусов. Замечаю нюанс: ulimit во freebsd не показывает ограничения на кол-во тредов. В мане (bash) ключ "-T" есть, а в самой утилите -- нет. В линуксе, кстати, man правильнее, ключ там не указан.
И тут наступает прозрение.
sysctl kern.threads.max_threads_per_proc: 1500Уменьшаю кол-во тредов до тысячи, работает. Поднимаю до полторы тысячи, перестает.
Меняю на max_threads_per_proc до 2000, и сразу все как по маслу.
Никогда програмисты сами не научатся создавать сообщения об ошибках, точно отражающие ситуацию, если их жестоко не пинать. По себе знаю. :(
четверг, 10 июня 2010 г.
Оформление исходных текстов
Заболел! Летом, блин!
И вот решил побрюздать, по мелочи, на избитые темы.
О стилях кодирования говорилось много. Существуют стронники жесткого следования стилю, сторонники допустимых послаблений. Есть те, кто плюют на всех -- "пишу как хочу".
Благодаря моему непосредственному начальнику я давно стал сторонником строгого следования в собственных исходных текстах (своих и рабочих). Места, которые вынуждено соприкасаются с внешним кодом, могут использовать другой name-convention для сглаживания перехода. В зависимости от инструмента (языка программирования), становится очевидно, что может быть применено и может ли вообще. Есть места, которые могут иметь отклонения и варианты. Все это оговаривается на начальных стадиях, каждый участник работы подтверждает согласие пользоваться стилем, и ему следуют.
Просто стиль должен быть естественным, логичным и обдуманным. Даже в мелочах.
Но бывает, что читаю о людях, которые утверждают, что ему удобнее (он привык), например, не ставить пробел после управляющего слова, а ставить его после скобок. И скулят, что его свободу ущемляют, когда за подобные места делается замечание.
Есть языки, в которых присутствуют некоторые особенности: как синтаксиса языка, так и стиля, устоявшегося в его сообществе. Да, подобное логично учитывать (в той или иной мере), при составлении своего стиля оформления. Никто не говорит, что исходные тексты языков программирования всегда могут быть похожи на естественные языки. Некоторые моменты вводить невозможно физически, или просто не целесообразно.
Но вой о том, что свободу ущемляют, это просто превыше моих сил. Свой псевдокомфорт ставится выше, чем продуктивность всей команды. Если вы считаете, что круче своей команды вместе взятой, так работайте один. Если нет, и ваши дурные привычки для вас важнее, то вы хуже избалованного ребенка, ковыряющего пальцем в носу на людях, и хнычущего, когда его отрывают (было ведь так хорошо и удобно). Более слабые и сильные коллеги должны читать вашу "резьбу по коду", в самих исходниках, в "патчах"/"диффах", и видеть ваше неуважение к ним в элементарных вещах.
Я не говорю, что никто не допускает ошибок, не забывается -- это все естественно. Но во-первых, следить за оформлением совсем не трудно, и это хорошая привычка. Во-вторых, уже давно есть автоматические оформители исходников, которые можно запускать перед "коммитами" (хоть автоматически). В конце-концов, если пользуетесь IDE, то все современные продукты можно настроить на использования нужного стиля, оно автоматически за вас все сделает.
Сознательное нежелание использовать общий стиль, попытка выделиться в такой мелочи и сделать исходники неоднородными -- неуважение к коллегам, к их времени. Однородные исходники читаются и обозреваются намного лучше. Чтение исходников -- значительная часть рабочего времени, а это время ваше, и ваших коллег.
Привыкайте, блять, уважать чужой труд!
И вот решил побрюздать, по мелочи, на избитые темы.
О стилях кодирования говорилось много. Существуют стронники жесткого следования стилю, сторонники допустимых послаблений. Есть те, кто плюют на всех -- "пишу как хочу".
Благодаря моему непосредственному начальнику я давно стал сторонником строгого следования в собственных исходных текстах (своих и рабочих). Места, которые вынуждено соприкасаются с внешним кодом, могут использовать другой name-convention для сглаживания перехода. В зависимости от инструмента (языка программирования), становится очевидно, что может быть применено и может ли вообще. Есть места, которые могут иметь отклонения и варианты. Все это оговаривается на начальных стадиях, каждый участник работы подтверждает согласие пользоваться стилем, и ему следуют.
Просто стиль должен быть естественным, логичным и обдуманным. Даже в мелочах.
Но бывает, что читаю о людях, которые утверждают, что ему удобнее (он привык), например, не ставить пробел после управляющего слова, а ставить его после скобок. И скулят, что его свободу ущемляют, когда за подобные места делается замечание.
if( expr)Люди, не порите чушь -- "она визжит и брыкается". Вы, когда пишете по-русски, ставите пробел перед открывающейся скобкой, и наоборот, не ставите пробел за ней. Делаете это автоматически и не причитаете о каких-то ущемлениях. Более того, грамотно писать вы уже привыкли (если вообще умеете), вас этому долго учили. Так чего же вы теперь выебываетесь?! Т.е. десять лет вы привыкали писать с соблюдением одного стиля, а потом за пару лет привыкли писать нарушая правила? Вас что, пиздили, чтобы добиться нужного эффекта? Более того, в своих ЖЖ-шечках вам удобно писать по-русски правильно, а в исходниках меняется мировоззрение?
if ( expr)
Есть языки, в которых присутствуют некоторые особенности: как синтаксиса языка, так и стиля, устоявшегося в его сообществе. Да, подобное логично учитывать (в той или иной мере), при составлении своего стиля оформления. Никто не говорит, что исходные тексты языков программирования всегда могут быть похожи на естественные языки. Некоторые моменты вводить невозможно физически, или просто не целесообразно.
Но вой о том, что свободу ущемляют, это просто превыше моих сил. Свой псевдокомфорт ставится выше, чем продуктивность всей команды. Если вы считаете, что круче своей команды вместе взятой, так работайте один. Если нет, и ваши дурные привычки для вас важнее, то вы хуже избалованного ребенка, ковыряющего пальцем в носу на людях, и хнычущего, когда его отрывают (было ведь так хорошо и удобно). Более слабые и сильные коллеги должны читать вашу "резьбу по коду", в самих исходниках, в "патчах"/"диффах", и видеть ваше неуважение к ним в элементарных вещах.
Я не говорю, что никто не допускает ошибок, не забывается -- это все естественно. Но во-первых, следить за оформлением совсем не трудно, и это хорошая привычка. Во-вторых, уже давно есть автоматические оформители исходников, которые можно запускать перед "коммитами" (хоть автоматически). В конце-концов, если пользуетесь IDE, то все современные продукты можно настроить на использования нужного стиля, оно автоматически за вас все сделает.
Сознательное нежелание использовать общий стиль, попытка выделиться в такой мелочи и сделать исходники неоднородными -- неуважение к коллегам, к их времени. Однородные исходники читаются и обозреваются намного лучше. Чтение исходников -- значительная часть рабочего времени, а это время ваше, и ваших коллег.
Привыкайте, блять, уважать чужой труд!
Подписаться на:
Сообщения (Atom)