Archive for Сентябрь, 2008

Ябедничать – очень-очень хорошо.

Понедельник, Сентябрь 29th, 2008

Я думаю, все хорошо помнят из детства простую истину «Ябедничать – плохо». Чуть подрос она заменялась на мягко говоря отрицательное отношение к «стукачеству». В общем, на территории exUSSR бытовала (и бытует) простая мысль – «Ты только попробуй пожаловаться, мы быстренько с тобой разберемся».

Я не буду вдаваться глубоко откуда это взялось. Я не знаток истории. Единственно, что похоже оно пришло из воровского кодекса (об этом писал мой брат).

Так вот, то, что хорошо ворам, то плохо для всех остальных. А мы не вдумываясь впитали это и активно применяем.

К чему это я веду? А веду я к тому, что единственный метод поддерживать хорошую конкуренцию на рынке (а значит нормальное отношение к потребителю и т.п.) – это предоставлять обратную связь.

Вам нахамили, обсчитали, пытались повесить лапшу на уши – вы пишите в книгу отзывов, звоните начальнику, рассказываете друзьям. Ясно, что от одного звонка плохая компания не закроется, а хорошая не вырастит на ее месте, но при этом постепенное накопление этих жалоб будут перераспределять соотношение в пользу лучших компаний и лучших работников.

Кстати, черт с ними с компаниями. Это действительно может занять годы, чтобы плохая компания вышла с рынка, а хорошая ее заняла.
Подумайте о другом. В компании есть два человека – один работает плохо, другой хорошо. Пока вы не сообщите об этом, они будут получать одинаковые деньги. Единственный метод зачастую дифференцировать таких людей – именно ваша жалоба на одного и похвала другого.

В общем, хотите видеть плохие компании мертвыми и плохих рабочих уволенными, а хорошие компании и людей премированными – ябедничайте, ябедничайте и еще раз ябедничайте.

Нужна помощь зала (по поводу мыслей о сервере).

Пятница, Сентябрь 26th, 2008

Я вот тут в раздумьи.

Мне нужен сайт, SVN, что-то из bug tracker’ного софта. Возможно еще что-то по ходу понадобится. Совсем свой (под кроватью) сервер я держать для этого не хочу.

Соответственно, я раздумываю над двумя возможностями.

а) Купить виртуальный хостинг и туда это все запихнуть.

Плюс состоит в том, что на этом сервере можно, что хотеть то и делать, хоть польку танцевать. То есть не проблема иметь там весь нужный софт и если что-то нужно – доставить.

Второй плюс, что все это (особенно код) живет не у чужого дядьки (который, может очень любить заглядывать в чужие SVN), а на своем сервере.Хотя это пожалуй у меня параноя.

Минус, то что всю это фиготень нужно поддерживать в рабочем виде, на что уйдут время или деньги, что в конечном итоге – деньги.

б) Всякие службы типа SVN и т.п. запихнуть на готовые хостинги.

Минусы, то что оно разбросано. Вероятнее всего сумма стоимостей хостингов будет больше чем виртуального сервера. Ну и нельзя свой софт ставить.

Плюсы – то, что обслуживается все это другими людьми и времени/денег на обслуживание тратиться меньше.

Что скажет общественность? Какой вариант предпочтительней и не ту ли третьего варианта (особенно если он мне сулит решение всех проблем).

Ацпект.

Четверг, Сентябрь 25th, 2008

Сижу вот я на завалинке, читаю книжку про аспектное программирование. Блин, умные же люди бывают. И придумается им такое.

В общем, если вы не слышали, то в двух словах идея следующая. Ну скажем у нас есть 3 класса и в каждом несколько функций и вот в каждой функции мы в самом начале например проверяем, что у пользователя есть права делать действие, которое там в функции описано. То есть получается, что вроде требование у нас одно – проверять права, а код размазан по черт знает какому количество мест (что соответственно не есть хорошо). Плюс, не просто код размазан, но еще и разбираясь и так с непростыми классами постоянно взглядом елозишь по кучи вот такого размазанного кода.

Так вот, возвращаясь к умным людям. Они, что же придумали. Что можно описать в отдельном файле что-нибудь типа – в начале всех функций класса A, и функций x,y класса B – делать проверочку прав и только если она прошла то вызывать саму функцию. Выходит, что и овцы целы (классы продолжают делать, что им положены) и волки сыты (авторизацию проводим).

Скажу сразу, что пока я не добрался до места в книге, где описано, как это реализовано. Какое-то странное предчувствие, что для языков с сложным синтаксисом и большим количеством разных изысков (читай C++) , движок это поддерживающий должен быть мягко говоря сложным.

Тем не менее, думаю, что это действительно следующий шаг за ООП. Хотя он конечно, призван не заменить, а дополнить его.

Интересно вообще, какого граница декомпозиции и компактности языков программирования? Думаю вопрос на самом деле не корректный, но тем не менее…

Просто, по большему счету фактически все развитие языков идет по следующему циклу

а. Решаем задачу

б. Обнаруживаем, что с одной стороны, у нас есть какое дублирование и с другой стороны есть размазанность связанного кода и нету языковых методов решить это.

в. Изобретаем новые методы, решаем этими методами проблему из б)

г. Увеличиваем размер задач.  Переходим на пункт а)

Собственно интересует предел буковки в). Ведь можно себе представить ситуация, когда попытка оптимизации и упрощения уже не будет приводить к результатам (ну типа, как попытка заархивирвоать уже заархивированный файл).

Вот такая, вот сборка мыслей по поводу аспектного программирования.

Так что, очень рекомендую почитать что-то по этому поводу. Прекрасно прочищает мозги.

Кстати, у меня есть стандартный вопрос на собеседование – «Чем вам НЕ нравиться язык X (вставить нужное)?».Похоже, добавлю в свой список вопрос – «Чем вам НЕ нравиться ООП»? Вот будет забавно поглядеть, как люди буду дергаться и нервничать.

А какой у вас бюджет?

Понедельник, Сентябрь 22nd, 2008

Знаете, частенько бывает ситуация, когда приходишь скажем в магазин, заказать визитки. И в магазине спрашивают – «А какой у вас бюджет?»

Так вот. Если вы заказчик – не спешите озвучивать свою бюджет. А то выходит следующим образом, предположим мы говорим цену X, если у них в уме была цифра Y < X, то они соглашаются на X, и таким образом мы сами себе взвентили цену.

Если у них была в уме цена Z > X, то они говорят: У… Вы знаете, меньше чем за Z мы сделать не можем.

По этому поводу. Говорение бюджета заранее – это изначально проигрышная стратегия.

Пару замечаний

а) Если вы исполнитель – спрашивать такое можно, но стоит делать аккуратно. С одной стороны для вас это беспроигрышная стратегия. С другой стороны, можно и спугнуть, так как для клиента это безвыигрышная стратегия.

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

P.S. По обсуждению. Наиболее нормальна такая ситуация, когда клиент только начинает поиск и нуждается в данных от рынка. Когда рынок исследован, то уже нормально называть свою бюджет. Единственно «но», является то, что если все таки первой называет цифру компанияю, то эта цифрма (сравненная с рынком) является одним из показателей «нормальности» компании. В случае озвучивания цены клиентом, он теряет возможность получить этот параметр от компании.