Не очень люблю такие посты на хабре: пройти мимо, не прокомментировав, не могу, а поскольку всегда пишу то, что думаю — сливают карму.
Мне ваш пост понравился, хотя со многими пунктами я категорически не согласен.
16. Мстите за обиды.
Нужно уметь прощать. Когда ты простил — ты «отпускаешь» обиду, твоя душа успокаивается. А если ты помнишь зло и вынашиваешь планы по мести — это будет разрушать тебя из нутри.
24. Обманывайте, если это способствует продвижению догм
Если вы обманываете кого-то, это опять-таки повреждает прежде всего вашу душу, независимо от того маленькая ложь или большая. Я не вижу причин, по которым мне потребовалось бы кого-то обманывать.
23. Никого и ничего не бойтесь.
Тоже весьма спорный пункт. Например, пару лет назад я был один и совершенно не боялся смерти. Сейчас у меня жена и ребенок, и если со мной что-то случится — кто тогда о них позаботится?
Повторюсь: пост понравился. И такие посты важно и нужно публиковать. Но не на хабре.
Минусующие как вы резко снижают общий уровень хабра.
Поскольку пропадает желание писать на хабр вообще.
Статья хорошая и ставить минус за то что «автор анонимен» неправильно.
Много воды, много картинок, ожидал от статьи большего.
Вывод тоже очень и очень неоднозначный. У каждого хорошего специалиста есть свои наработки, созданные за годы кропотливой работы и размножающиеся обычно копипастом. Как быть с ними при часовой оплате труда? Не использовать и писать все заново или скопировать и получить деньги за пять минут работы?
А вот большой процент людей, не вникшим ни в какую суть, но желающих покритиковать, огорчает.
Таков сейчас хабр. Если ваше мнение отлично от мнения большинства — вас минусуют, даже не пытаясь ни в чем разобраться. Причем независимо от того, насколько вы правы/неправы или какие аргументы вы в свою пользу приводите.
P.S. Знаю, что за этот комментарий меня тоже скорей всего заминусуют, но хочется вас поддержать. Повторюсь, некоторые ваши идеи (да и сам проект тоже) достаточно интересны и заслуживают должного внимания.
Мне кажется, что ваш проект SKY еще в начале пути, во всяком случае вы позиционируете его как php-ядро для создания сайтов, а сам ваш сайт по уровню, честно говоря, слабоват (на мой взгляд).
Но сама идея у вас очень и очень интересная, поэтому спокойно относитесь к критике — у вашего проекта есть и достаточный потенциал, и хорошие перспективы.
Был удивлен, что из-за «Перегорания» гибнет лишь 8% стартапов. На моей памяти несколько стартапов так и не вышли в свет именно из-за того, что разработчики «перегорели» и команда распалась. В стартапе ведь обычно хоть и дают долю в проекте, но платят при этом мало. А когда пару-тройку месяцев сидишь лишь над одним и тем же проектом, да еще и за малые деньги, то невольно возникает вопрос «да зачем мне все это нужно?».
Как еще одну причину хочется указать «чувство несправедливости распределения долей»: Петя по пол дня в ненапряг работает и у него доля 15%, а я тут горбачусь с утра до вечера и у меня лишь 10% — непорядок.
Сам я участвовал в нескольких стартапах, завершен был лишь один, да и тот в итоге загнулся.
В разработке руководствуюсь правилом: «исключения для программистов, а не для пользователей.»
То есть если пользователь забыл ввести значение в поле формы — это просто ошибка, не исключение.
А вот если где-то «внутри» очень важная переменная вдруг оказалась не заданной — нужно кидать исключение, причем вывести и имя функции, и сообщение, и значения других параметров, которые помогут найти эту ошибку.
Статья очень понравилась. Спасибо.
Хочу только добавить, что хабр меняется, причем, на мой взгляд, не в лучшую сторону.
Если раньше это было место, где можно было получить хорошую обратную связь (как раз от тех 5% экспертов, о которых вы упомянули), то сейчас это скорее место для пиара своей компании/своего продукта.
А мне статья понравилась. Не понимаю, за что человека заминусовали, многие вещи как минимум заслуживают внимание, причем гораздо большего, нежели дискуссии на тему «табы vs пробелы».
Вот с чем не согласен:
01) Если давать короткие имена вида «а1», «а2», то потом очень сложно находить нужные места поиском.
Например, часто требуется подкорректировать все места, где встречается какой-то определенный объект.
02) Комментировать нужно. Но преимущественно те места, в которых у другого разработчика могут возникнуть трудности с пониманием, а что именно ты пытался сделать. Порой в чужом коде очень сложно понять, для чего именно тот или иной кусок кода.
Существует достаточно много редакторов отчетов, позволяющих экспортировать и в pdf, и в excel, и в html.
Гляньте на досуге FastReports (возможно как раз то, что вам требуется).
Идеи у вас достаточно интересные, хоть и о-о-очень сырые. Но мне кажется, что вы вновь движетесь не совсем в правильном направлении. Мне, например, не очень хочется жить в мире, где всем заправляют роботы или автоматизированная система. В подобном мире значимость отдельно взятого человека понижается практически до нуля. Я не хочу жить в мире, где люди лишь спят, едят и в танки играют.
В тоже время в нашем сегодняшнем мире достаточно много талантливых людей, которые вместо того, чтобы развивать свой талант вынуждены пахать как папа Карло на нелюбимой работе. Вот для них, думаю, стоит что-нибудь эдакое сделать, дабы дать им возможность не зарывать свой талант в землю.
В общем, мое мнение: вам следует начать с небольшой волонтерской благотворительной организации, а уж что из этого выльется — время покажет.
Я наверное вновь буду «белой вороной», но все же выскажу мнение, что между скоростью и качеством выбирать лучше все-таки первое. Мир ускоряется, и сейчас реалии таковы, что основным фактором является вовсе не качество, и даже не стоимость, а именно время разработки.
Для заказчика лучше иметь хоть какую-нибудь, пусть сырую и с багами, но работающую систему/проект сегодня, нежели красивенькую и стабильную, но не пойми когда в будущем. Особенно это характерно для стартапов, когда еще совершенно неясно «работающая» у вас идея или ерунда полнейшая.
Хотя, признаюсь честно, когда в штате есть свой тестировщик работать одно удовольствие.
В исходном файле words.txt есть слова, которые отличаются лишь регистром (например, ABEL, Accra).
Их не так уж и мало — приблизительно 31 000, привожу скрипт (mysql) для их выборки:
SELECT word, COUNT(*) AS quality
FROM words_good
GROUP BY LOWER(word)
HAVING quality > 1
Думаю, их стоит исключить из списка, поскольку по условиям задачи все слова будут в нижнем регистре.
В выборе на чем разрабатывать проект основную роль, на мой взгляд, является поставленная перед вами задача.
Если вам требуется создать сайт-визитку, интернет-магазин или блог — тогда лучше использовать какое-нибудь готовое решение.
А если требуется именно функционал (учет заявок, печать квитанций, отчеты и т.д.) — лучше конечно же фреймворк.
Статья не очень — общие советы, мало конкретики.
А вот приложение на видео кажется мне достаточно интересным и имеет достаточно высокие шансы на успех.
Думаю, вам не стоит забрасывать разработку, откладывая все на «потом когда-нибудь». Вы ведь, как я смог понять, тоже программист => при желании сможете освоить и мобильную разработку.
Логи изменений или логи состояний? Иными словами, дифы или снепшоты?
Причем здесь дифы и снепшоты? Логи не на уровне БД, а на уровне приложения. Т.е. грубо говоря, заказчик хочет зайти на сайт/в программу и увидеть, кто какие вносил изменения (например, кто поменял номер в накладной).
(Более того, когда у заказчика есть возможность редактировать хранимые процедуры, от которых зависит приложение — его поддержка превращается в ад. Жизненная история.)
Опять-таки причем здесь доступ к хранимым у заказчика? Это категорически недопустимо!
Хранимые и вьюшки являются своего рода интерфейсами подобно api в сайте. Позволяют как менять структуру базы без необходимости ребилдов основного приложения (которое может быть установлено на непойми скольких компьютерах), так и запрещать доступ пользователям к бд напрямую.
Хорош, я приведу вам несколько примеров, в которых при вашем подходе к проектированию могут возникнуть сложности.
Например, вам требуется вести логи изменений в тех или иных таблицах. Заказчик, естественно, хочет в таблице логов видеть отсылку к элементу (возможность "открыть" страницу/форму элемента). Для этого в таблицу логов просто добавляется поле "elemid". Это к вопросу, что id лучше делать числовым. Пояснять, почему в таблицу логов поле "elemid" лучше сделать числовым, пожалуй, не буду.
Второй пример к вопросы, почему желательно называть "id", а не "BookId", "AuthorId". Например, у вас есть универсальная хранимая процедурка с каким-нибудь алгоритмом обработки. На вход поступает список имен таблиц, внутри формируется текст запроса и вызывается через bulk_cmd, результаты фиксируются в какой-либо таблицы (мол, элемент такой-то обработан). Если у разных таблиц будут по разному названы ключевые поля, то придется их передавать еще одним параметром.
PS.
А никаких, кстати. Особенно если в приложении писать не SQL-код, а код, нативный для приложения, который транслируется в SQL-код.
Вы правда так думаете? Я, например, с вами не согласен. Например, по сети лучше передавать имя хранимой с параметрами, чем длинный текст кода. Или, например, порой требуется иметь возможность редактирования алгоритма без перекомпиляции приложения (т.е. приложение уже у заказчика, а тут появляется необходимость по другому записывать поля).
Кроме неоходимости повторять код — никаких. Учитывая, что в большей части случаев я имею дело со сгенеренными кодом — и вовсе никаких.
На это я даже не знаю, что вам ответить. Вы, видимо, просто нечасто пользуетесь данным инструментом, поэтому и не очень много знаете о возможностях, которые он предоставляет.
А какие трудности у вас возникнут если поля BookId и AuthorId назвать Field01 и Field02? Это же не запрещено?
А какие трудности возникнут, если при добавлении записей одновременно в две простые таблицы (т.е. вы твердо убеждены, что ошибок при insert'е быть не может) их не оборачивать в транзакцию?
А какие трудности возникнут, если большие куски sql-кода не заключать в хранимые процедуры а писать прямо в приложении?
А какие трудности возникнут, если не использовать вьюшки, а использовать вместо них просто вызовы select'а?
Какие вообще могут быть трудности, если не следовать общепринятым правилам?
Я немного вклинюсь в вашу беседу.
Существуют определенные "негласные" правила проектирования. Так вот то, что в таблице должно быть поле под названием "id" и быть оно должно автоинкрементным — это как раз и считается "правилом хорошего тона". Вы конечно можете этому не следовать, но тогда на практике у вас могут возникнуть разного рода трудности.
Хабр уже не тот. Нет, я не говорю что все плохо, профессионалы здесь бесспорно присутствуют, но их значительно меньше, нежели ребят, которые понабрались умных словечек и теперь просто сыплются ими с умным видом направо и налево (а-ка "попробуйте ВотЭто", или "есть же ВотЭто"). А ты сидишь и думаешь: а он вообще статью-то читал? Так обидно было видеть, как двух авторов с довольно интересными идеями просто "сливают", даже не вникая в их разработки.
Мне ваш пост понравился, хотя со многими пунктами я категорически не согласен.
Нужно уметь прощать. Когда ты простил — ты «отпускаешь» обиду, твоя душа успокаивается. А если ты помнишь зло и вынашиваешь планы по мести — это будет разрушать тебя из нутри.
Если вы обманываете кого-то, это опять-таки повреждает прежде всего вашу душу, независимо от того маленькая ложь или большая. Я не вижу причин, по которым мне потребовалось бы кого-то обманывать.
Тоже весьма спорный пункт. Например, пару лет назад я был один и совершенно не боялся смерти. Сейчас у меня жена и ребенок, и если со мной что-то случится — кто тогда о них позаботится?
Повторюсь: пост понравился. И такие посты важно и нужно публиковать. Но не на хабре.
Поскольку пропадает желание писать на хабр вообще.
Статья хорошая и ставить минус за то что «автор анонимен» неправильно.
Вывод тоже очень и очень неоднозначный. У каждого хорошего специалиста есть свои наработки, созданные за годы кропотливой работы и размножающиеся обычно копипастом. Как быть с ними при часовой оплате труда? Не использовать и писать все заново или скопировать и получить деньги за пять минут работы?
P.S. Знаю, что за этот комментарий меня тоже скорей всего заминусуют, но хочется вас поддержать. Повторюсь, некоторые ваши идеи (да и сам проект тоже) достаточно интересны и заслуживают должного внимания.
Но сама идея у вас очень и очень интересная, поэтому спокойно относитесь к критике — у вашего проекта есть и достаточный потенциал, и хорошие перспективы.
Как еще одну причину хочется указать «чувство несправедливости распределения долей»: Петя по пол дня в ненапряг работает и у него доля 15%, а я тут горбачусь с утра до вечера и у меня лишь 10% — непорядок.
Сам я участвовал в нескольких стартапах, завершен был лишь один, да и тот в итоге загнулся.
То есть если пользователь забыл ввести значение в поле формы — это просто ошибка, не исключение.
А вот если где-то «внутри» очень важная переменная вдруг оказалась не заданной — нужно кидать исключение, причем вывести и имя функции, и сообщение, и значения других параметров, которые помогут найти эту ошибку.
Хочу только добавить, что хабр меняется, причем, на мой взгляд, не в лучшую сторону.
Если раньше это было место, где можно было получить хорошую обратную связь (как раз от тех 5% экспертов, о которых вы упомянули), то сейчас это скорее место для пиара своей компании/своего продукта.
Вот с чем не согласен:
01) Если давать короткие имена вида «а1», «а2», то потом очень сложно находить нужные места поиском.
Например, часто требуется подкорректировать все места, где встречается какой-то определенный объект.
02) Комментировать нужно. Но преимущественно те места, в которых у другого разработчика могут возникнуть трудности с пониманием, а что именно ты пытался сделать. Порой в чужом коде очень сложно понять, для чего именно тот или иной кусок кода.
Гляньте на досуге FastReports (возможно как раз то, что вам требуется).
В тоже время в нашем сегодняшнем мире достаточно много талантливых людей, которые вместо того, чтобы развивать свой талант вынуждены пахать как папа Карло на нелюбимой работе. Вот для них, думаю, стоит что-нибудь эдакое сделать, дабы дать им возможность не зарывать свой талант в землю.
В общем, мое мнение: вам следует начать с небольшой волонтерской благотворительной организации, а уж что из этого выльется — время покажет.
Для заказчика лучше иметь хоть какую-нибудь, пусть сырую и с багами, но работающую систему/проект сегодня, нежели красивенькую и стабильную, но не пойми когда в будущем. Особенно это характерно для стартапов, когда еще совершенно неясно «работающая» у вас идея или ерунда полнейшая.
Хотя, признаюсь честно, когда в штате есть свой тестировщик работать одно удовольствие.
Их не так уж и мало — приблизительно 31 000, привожу скрипт (mysql) для их выборки:
Думаю, их стоит исключить из списка, поскольку по условиям задачи все слова будут в нижнем регистре.
Если вам требуется создать сайт-визитку, интернет-магазин или блог — тогда лучше использовать какое-нибудь готовое решение.
А если требуется именно функционал (учет заявок, печать квитанций, отчеты и т.д.) — лучше конечно же фреймворк.
А вот приложение на видео кажется мне достаточно интересным и имеет достаточно высокие шансы на успех.
Думаю, вам не стоит забрасывать разработку, откладывая все на «потом когда-нибудь». Вы ведь, как я смог понять, тоже программист => при желании сможете освоить и мобильную разработку.
Причем здесь дифы и снепшоты? Логи не на уровне БД, а на уровне приложения. Т.е. грубо говоря, заказчик хочет зайти на сайт/в программу и увидеть, кто какие вносил изменения (например, кто поменял номер в накладной).
Опять-таки причем здесь доступ к хранимым у заказчика? Это категорически недопустимо!
Хранимые и вьюшки являются своего рода интерфейсами подобно api в сайте. Позволяют как менять структуру базы без необходимости ребилдов основного приложения (которое может быть установлено на непойми скольких компьютерах), так и запрещать доступ пользователям к бд напрямую.
На остальное даже отвечать желания нету..
Например, вам требуется вести логи изменений в тех или иных таблицах. Заказчик, естественно, хочет в таблице логов видеть отсылку к элементу (возможность "открыть" страницу/форму элемента). Для этого в таблицу логов просто добавляется поле "elemid". Это к вопросу, что id лучше делать числовым. Пояснять, почему в таблицу логов поле "elemid" лучше сделать числовым, пожалуй, не буду.
Второй пример к вопросы, почему желательно называть "id", а не "BookId", "AuthorId". Например, у вас есть универсальная хранимая процедурка с каким-нибудь алгоритмом обработки. На вход поступает список имен таблиц, внутри формируется текст запроса и вызывается через bulk_cmd, результаты фиксируются в какой-либо таблицы (мол, элемент такой-то обработан). Если у разных таблиц будут по разному названы ключевые поля, то придется их передавать еще одним параметром.
PS.
Вы правда так думаете? Я, например, с вами не согласен. Например, по сети лучше передавать имя хранимой с параметрами, чем длинный текст кода. Или, например, порой требуется иметь возможность редактирования алгоритма без перекомпиляции приложения (т.е. приложение уже у заказчика, а тут появляется необходимость по другому записывать поля).
На это я даже не знаю, что вам ответить. Вы, видимо, просто нечасто пользуетесь данным инструментом, поэтому и не очень много знаете о возможностях, которые он предоставляет.
А какие трудности возникнут, если при добавлении записей одновременно в две простые таблицы (т.е. вы твердо убеждены, что ошибок при insert'е быть не может) их не оборачивать в транзакцию?
А какие трудности возникнут, если большие куски sql-кода не заключать в хранимые процедуры а писать прямо в приложении?
А какие трудности возникнут, если не использовать вьюшки, а использовать вместо них просто вызовы select'а?
Какие вообще могут быть трудности, если не следовать общепринятым правилам?
Существуют определенные "негласные" правила проектирования. Так вот то, что в таблице должно быть поле под названием "id" и быть оно должно автоинкрементным — это как раз и считается "правилом хорошего тона". Вы конечно можете этому не следовать, но тогда на практике у вас могут возникнуть разного рода трудности.