2468

Заметки "Тыжпрограммиста" #3

Как отомстить клиенту, который кинул тебя на деньги? Удалить сайт, или придумать изощренный сопосб мести? В этом посте - история про первое крупное кидалово и про очень необычный проект, который запустится только после 2020 года.


Клиент 09


Обратился ко мне как-то дядька очень перспективный. С просьбой сделать сайт как у "ТАСС", только круче. Дядька, к слову, очень придирчивый оказался. Сайт я ему сделал за три дня, и еще две недели я менял всякие несущественные мелочи - иконка просмотров должна быть строго с отступом в 2 пикселя от блока, отображение блоков с новостями должно быть точно такое же как у сайта "ведомости". В-общем две недели с лишним я мудохался с этим сайтом, пока он мне не заявил что моя работа его не устраивает и он прекращает со мной всякие отношения. Моей ошибкой было то, что я разместил сайт на его хостинге. После этого заявления доступ к хостингу и сайту у меня естественно пропал. Никаких пасхалок я ему не успел оставить, кроме одной. Даже не пасхалки а послания будущим программистам. Есть у меня тупая привычка - комментировать код аля "микроблог". В каком-то из файлов движка я написал примерно следующее:

Заметки "Тыжпрограммиста" #3

Через полгода примерно со мной на связь вышел программист , который нашел мою почту в исходном коде в мета-тегах "Автор сайта" и почитал мои незамысловатые послания в коде. И спросил как ему изменить в форме добавления новостей структуру. Т.е. добавить новые поля и т.д. Я очень обрадовался тому факту, что данный человек меня нашел. Объяснил ему ситуацию, рассказал что кинул заказчик этого сайта и во мне кипит жажда мести. Парень оказался понимающим и согласился мне помочь наказать негодяя. Правда за гонорар, который ему пообещал владелец сайта. Хорошо, что на тот момент деньги были и я смог заплатить чуваку за доступы и молчание. Я не стал отключать сайт и писать на нем страшные надписи о ненадежности хозяина. Просто добавил на сайт второго пользователя с правами администратора и написал скрипт, который все слова в заголовках и текстах добавляемых новостей перемешивает рандомно. То есть вместо "Компания Газпром будет финансировать новый проект в 2018 году" заголовок получался при сохранении таким: "2018 компания в Газпром новый финансировать проект году будет". Естественно, хозяин сайта стал сильно беситься и искать людей, которые исправят это дело. Но так как всем будущим претендентам на работу с сайтом в исходном коде было оставлено письмо о том, что их кинут, то ошибка не устранялась.


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


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


Клиент 010


Некоторые клиенты уверены, что у них есть просто гениальные идеи, которые принесут им миллиарды, как Цукербергу. Обратился ко мне как-то парень с действительно очень прикольной идей - он захотел создать биржу фриланса для битмэйкеров. Биржа должна была работать следующим образом: битмэйкер регистрируется на сайте и выкладывает на него свои минусовки, указывает стоимость и т.д. А покупатели (рассчитывалось что ими будут музыканты и продюссеры) могут эти минусовки слушать, и покупать понравившиеся.


Если мне нравится проект сайта, я берусь за него с большим энтузиазмом. Сам советую какие-нибудь прикольные фишки, пишу действительно нормальный функционал. И все было нормально до поры до времени. Пока моего клиента не повязал ГНК с крупной партией наркотиков. Не могу точно рассказать подробности, но теперь мой заказчик сидит в тюрьме. Последним его сообщением мне было:


"Сайт нужно доделать. Ты допиши его, деньги если что достанем. Только без меня не запускай"


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


© Гудмикс блог

IT-юмор

7K постов53.2K подписчиков

Правила сообщества

Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору

Вы смотрите срез комментариев. Показать все
76
DELETED
Автор поста оценил этот комментарий
Я конечно сам вебразраб...
Но, прочитав, стори про клиента 09 теперь знаю как развести программера не только на изготовление сайта, но ещё и на бабки.

PS: if ($category_id && $category_id > 1) - первое условие или убрать или полноценнее проверять
раскрыть ветку (139)
67
Автор поста оценил этот комментарий

так и знал что зайдя в комменты увижу срачь по поводу кода ))))

Иллюстрация к комментарию
раскрыть ветку (1)
24
Автор поста оценил этот комментарий

Оказывается, есть и такие :)

Иллюстрация к комментарию
30
Автор поста оценил этот комментарий
Это не мой код. Выдернул из движка просто для примера того, как я обычно комментирую.
раскрыть ветку (26)
0
Автор поста оценил этот комментарий

А что за дживок?

ещё комментарии
11
Автор поста оценил этот комментарий
if ($category_id && $category_id > 1) - первое условие или убрать или полноценнее проверять
Давай я так спрошу - ты ДЕЙСТВИТЕЛЬНО не видишь ни одного варианта, при котором выбор такое написания будет правильным?
раскрыть ветку (98)
18
DELETED
Автор поста оценил этот комментарий
Скажи мне этот вариант и я скажу почему он говно. Обещаю не использовать аргумент: потому, что это php
раскрыть ветку (94)
8
Автор поста оценил этот комментарий
Это проверка на ошибки - отрицательные записи в БД.
раскрыть ветку (49)
6
DELETED
Автор поста оценил этот комментарий

Вот они, те люди, которые используют отрицательные ID. Если используешь unsigned, то проверка не нужна будет, так как mysql всё сделает за тебя.

раскрыть ветку (39)
0
Автор поста оценил этот комментарий
Не использует, а всегда проверяет, вспомните про самолёты над Мертвым морем.
раскрыть ветку (18)
5
DELETED
Автор поста оценил этот комментарий

Может тогда и составные ключи выбросить, которые обеспечивают уникальность, и будем перед вставкой ручками запрашивать БД на наличие дубликатов? Можем ещё отказаться от внешних ключей, которые позволяют каскадно изменять связанные строки.

раскрыть ветку (17)
2
Автор поста оценил этот комментарий
Каким образом мой комментарий привёл к таким предложениям?
раскрыть ветку (8)
1
DELETED
Автор поста оценил этот комментарий
Это проверка на ошибки - отрицательные записи в БД.
раскрыть ветку (7)
2
Автор поста оценил этот комментарий
Общепринято использовать в качестве главного ключа положительные значения. Поэтому если тебе в сете значений прилетел отрицательный ПК, то не стоит верить и тому, что прилетело после. База - таблицы- фактически массивы структур. Использовать отрицательные значения в качестве индексов массива... Ну так себе веселье.
раскрыть ветку (6)
1
DELETED
Автор поста оценил этот комментарий

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

раскрыть ветку (4)
0
Автор поста оценил этот комментарий
Почему отрицательные? I'd 1 не пройдёт проверку, может нужны все кроме первого.
0
Автор поста оценил этот комментарий
Чувак, ты агришься не по делу.

Лишняя проверка никогда никому еще не мешала.

раскрыть ветку (7)
0
DELETED
Автор поста оценил этот комментарий

По делу: цитирую коммент

Это проверка на ошибки - отрицательные записи в БД.

#comment_102973173

раскрыть ветку (6)
Автор поста оценил этот комментарий
Нет, не по делу.

С хуяли друже в базе не может быть отрицательных ИД?

По твоему отрицательные числа это такая блажь, которой в базе быть не должно?

раскрыть ветку (5)
0
DELETED
Автор поста оценил этот комментарий

Назови хоть один оправданный случай хранения отрицательного ID категории

раскрыть ветку (4)
0
Автор поста оценил этот комментарий
Вот они, те люди, которые используют отрицательные ID
Пилять.

Это не люди которые используют отрицательные ID.

Это люди которые знают что в любой момент откуда угодно может взяться отрицательный ID, даже если ты его не ожидал:)

Ты в курсе, например, что php unsigned int не поддерживает, поэтому большой 32 битовый инт отданный мускулом превратится в тыкву в пхп?
раскрыть ветку (19)
1
DELETED
Автор поста оценил этот комментарий

Я о типе unsigned в mysql. Этот механизм гарантирует отсутствие отрицательных ID. Почему все нормальные люди используют id как unsigned NOT NULL AUTO_INCREMENT?


Про возможность переполнения:

PHP на

- 64-битных системах максимальный  int: 9223372036854775807

- на 32-битных системах максимальный int: 2147483647


Mysql максимальный unsigned  int 4294967295


Как видно, на 64-битных системах всё ок.



Продублирую коммент:

Может тогда и составные ключи выбросить, которые обеспечивают уникальность, и будем перед вставкой ручками запрашивать БД на наличие дубликатов? Можем ещё отказаться от внешних ключей, которые позволяют каскадно изменять связанные строки.

ещё комментарии
1
Автор поста оценил этот комментарий
Чисто для проверки на отрицательность числа достаточно было бы второй части.
раскрыть ветку (8)
4
Автор поста оценил этот комментарий
А на null и существование?
раскрыть ветку (7)
0
DELETED
Автор поста оценил этот комментарий
Это php. Второй части бы хватило :) Или полноценно прописать проверку на существование и не null и инт и всё, что хочешь.
Автор поста оценил этот комментарий
null (и не существование) не пройдет первое условие, но и второе не пройдет. поэтому второго именно для этой цели достаточно.
раскрыть ветку (5)
2
Автор поста оценил этот комментарий
То есть если переменная не проинициализированна, то краша на первом условии не будет? Я просто из той области где любой указатель перед использованием всегда проверяется. Или в пыхе и джс по другому?
раскрыть ветку (4)
Автор поста оценил этот комментарий
php язык не строгой типизации.

ошибку уровня notice бросит (но всем на нее посрать будет), приведет null к 0 (при сравнении с целым) и все на этом.

раскрыть ветку (3)
1
Автор поста оценил этот комментарий
Как люди живут без строгой типизации?
раскрыть ветку (2)
3
DELETED
Автор поста оценил этот комментарий
Ну... Им иногда не платят за сделанную работу :)
Автор поста оценил этот комментарий

Нормально:)

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

В php 7.x ситуацию изрядно поменяли и теперь все намного проще.

0
Автор поста оценил этот комментарий

Долго думал над ситуацией, когда это может пригодиться. И, честно говоря, в голову ничего не пришло. Оставлю тут коммент, чтобы однажды вспомнить и почитать ветку снова. Может кто-то придумает.

0
DELETED
Автор поста оценил этот комментарий

if ($category_id > 1)

Автор поста оценил этот комментарий

Ты не ответил на вопрос.


Хотя по твоему ответу уже понятно.

Ты прекрасно понимаешь, что на самом деле ИНОГДА есть варианты, когда выбор такого написания будет правильным, просто ты заранее подготавливаешь себе пути съехать с темы заранее записывая их в говно:)

раскрыть ветку (40)
4
DELETED
Автор поста оценил этот комментарий
Если дашь пример варианта - обещаю уложиться в более развернутую версию обоснования "первое условие или убрать или полноценнее проверять" с которого всё и началось.
ещё комментарии
DELETED
Автор поста оценил этот комментарий

Допустим, при $category_id === [2], будет истинно.

Автор поста оценил этот комментарий

Чем тебя смущают заведомо ложные выражения?


... if ($category_id && $category_id > 1)

... where 1==2 - у них есть своя разная цель, догадайся, какая

раскрыть ветку (2)
0
DELETED
Автор поста оценил этот комментарий
То есть при первой проверке в $category_id лежит 1, а при второй - в той же самой переменной уже лежит двойка?
раскрыть ветку (1)
Автор поста оценил этот комментарий

Первый пример, наверняка, вроде камента - отключить блок.

Второй из SQL, ADO и т.п. ... долго объяснять.

0
Автор поста оценил этот комментарий
Я не шарю в пхп, но с динамически типизированными языками разве так не правильно иногда делать?
ибо в js, емнип, если переменная undefined, то оно крашнется на сравнении с 1
а так оно не пройдет первый иф
раскрыть ветку (2)
0
DELETED
Автор поста оценил этот комментарий
В пыхе не крашнется на сравнении и проверка на инициализацию выглядит иначе
0
Автор поста оценил этот комментарий
В js достаточно второй части и все будет ок.
0
Автор поста оценил этот комментарий
Тоже самое пришла написать))
Автор поста оценил этот комментарий
С пхп сильно не знаком, вот подскажите знающие люди каков результат когда category_id будет 0 или меньше?, если "ложь" то это пиздец ребята, как можно сравнить булево и числовые значения?...
раскрыть ветку (4)
Автор поста оценил этот комментарий
Первое условие на то, что переменная инициализирована, второе - больше нуля.
раскрыть ветку (2)
1
DELETED
Автор поста оценил этот комментарий
А isset в php зачем тогда?
раскрыть ветку (1)
0
Автор поста оценил этот комментарий
Хз, я только про js пиздеть умею
ещё комментарий
Автор поста оценил этот комментарий

не соглашусь. $category_id может не существовать и проверять не существующую переменную, на то что она больше еденицы  - вылезет warning, если на серваке включен показ ошибок.
Правильно проверять так:
if (!empty($category_id) && $category_id > 1).

А вообще конечно по хорошему надо ещё в селекте дёргаться категории у которых id больше единицы, дабы не выносить логику в контроллер\вьюху.

раскрыть ветку (1)
0
DELETED
Автор поста оценил этот комментарий
А с чем ты не согласен?
Я утверждаю, что нужно или убрать первое условие или организовать полноценную проверку - ты со словами несогласен предлагаешь неполноценную проверку :)
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку