За життя

From Security is ... series 2
Бензопила Кедр. Бажаю тим, хто так називав пилу, гризти горішки виключно з неї.
В то время как космические корабли бороздят просторы вселенной, вы приходите в магазин, где советского формата продавщица смотрит на вас с выражением лица "чего приперся?". У вас возникает когнитивный диссонанс между сказками о клиентоориентированности, которые вы можете прочесть в популярном блоге, и суровой действительностью.

Так вот ... Отставьте свойе кофе (чтобы поперхнувшись не заплевать им монитор), и узрейте истину.
  1. Любая система стремится к стабильности. (это - закон природы и правило №1 любой приличной философской школы, а если школа молчит об этом правиле, то бегите оттуда). Соответственно, система работает ради себя, для поддержания собственной стабильности. А не ради клиентов или социума. Клиентоориентированность - сказки для корпоративных тренингов и младшего персонала. А бизнес - по определению деятельность, направленная на получение прибыли (для себя любимого). Исключением являются так называемые социальные бизнесы, законодательно или социальными нормами (либо, реже, убеждениями владельцев) обязанные получать не более какой-то границы прибыли. Нет цели "удовлетворить клиента". Есть цель "получить прибыль, возможно путем удовлетворения клиента".
  2. Сотрудник компании - это не компания. У любого сотрудника компании существует свой собственный в этой компании интерес, и он не совпадает с интересом компании. Они (эти интересы) могут быть паралельны или временами пересекаться, но это разные интересы. Сотрудник не отождествляет себя с компанией, и тренинги по тим-билдингу призваны хоть как-то, хоть на чуть-чуть привить сотруднику ощущение сходности интересов и привязанности к компании. Конечно, есть исключения и есть люди, болеющие за [не] свое дело, но таких мало, и обычно это не рядовые работники, с которыми вы чаще всего общаетесь в компании. Поэтому аппелировать к сотруднику "я в вашей компании год обслуживаюсь" можно, конечно, но сотрудник может ответить "а я тут только пару месяцев работаю и задерживаться не собираюсь". Т.е. ему ваши отношения с компанией могут быть неинтересны, если только от этого не зависят его бонусы.
  3. Норма прибыли большинства бизнесов делает поддержку отдельно взятого клиента экономически невыгодной (опять таки, я говорю о массовом рынке, и везде есть исключения). Иными словами - как только вы обращаетесь в службу поддержки или в гарантийный ремонт или в отдел рекламаций, - вы автоматически становитесь для компании убыточным клиентом. Им неинтересно и невыгодно тратить на вас время. Да, конечно, открыто они вам этого не скажут, равно как и на дверь не покажут в большинстве случаев, но и церемониться с вами им ни к чему. Скорее всего даже если они потеряют вас как клиента, то это все равно будет выгоднее, чем долго и нудно с вами возиться.
  4. Для компании нет ничего хуже, чем клиент с неадекватными ожиданиями, т.е. человек, который приходит в компанию с установкой "мне все вокруг должны". Это человек, который настроен получить по максимуму за минимальные деньги (или бесплатно). Т.е. человек, активно противодействующий компании в ее целях получать прибыль. Естественно, что у сотрудников может быть даже прямое указание заворачивать таких клиентов, до того как они нанесут убыток компании. Поэтому запомните (и детям завещайте помнить) - в этом мире вам никто ничего не должен. С этой установкой вам стоит приходить в любую компанию или организацию. И тогда вы сможете убедить сотрудников компании или организации, что с вами можно и нужно вести дело.


Что же делать, чтобы получать хороший сервис и дружить с компаниями и организациями?
  1. урезать осетра ожидания. Чем ниже ваши ожидания, тем меньше вероятность разочароваться и тем больше шанс получить положительные эмоции и результат лучше ожидавшегося.
  2. помнить, что есть два пути решения любой проблемы - сотрудничество и соревнование. В соревновании ресурсы вычитаются. В сотрудничестве они складываются. Если вы начинаете соревноваться (спорить, ссориться) с сотрудником компании, вы тратите свои ресурсы, которые вы могли бы направить на что-то более полезное.
  3. выявлять интерес конкретного сотрудника. Напомню, что это для вас интересом является решить вашу проблему, а у сотрудника есть еще интерес не потратить на вас много времени / сил и попытаться на вас заработать (не говоря уже об интересе "уйди сегодня домой пораньше" и "как голова болит после вчерашнего").
  4. (следствие из предыдущих пунктов) помнить, что в правильно поставленном вопросе 80% ответа. Если вы обращаетесь к кому-то, четко сформулируйте ваш вопрос / претензию и предоставьте максимум относящейся к делу информации по вопросу.
  5. ну и наконец, помните, что у вас тоже есть свои клиенты (даже если вы работаете токарем на заводе или ассенизатором). А судьба - она хуже бумеранга, отдачей не промахивается.

Facebook's Reach Generator is a system that allows advertisers to pay a fixed fee to ensure that their content/ads will be seen by 75 percent of their fans. (Currently, the company estimates that a business's branded page reaches just 16 percent of fans on average.)

Перевожу на понятный язык: сначала мы не показываем ваши сообщения на вашей странице вашим же фанам, а потом берем с вас деньги, чтобы показывать.

Вот за этот наебизнес я и не люблю Apple и Facebook.
Черговий раз дякую, тобі, Боже, що я не москаль. PS: Хоча на іншому глобусі я б ще й в церкву ходив.

(написано для співробітників, публікується із незначними скороченнями)

Останні два тижні я вивчаю стан справ із розробкою для Web. Чим і хочу з вами поділитись.

15 років тому Delphi набула популярності в першу чергу завдяки концепції компонентів, тобто бібліотек коду, котрі легко вбудовувались в структуру і ієрархію класів самого засобу розробки. Загалом на ті часи на ринку був наявний обмежений перелік засобів розробки (під Windows як найбільш масову платформу), а саме Visual C++, Visual Basic, Delphi / C++Builder, пізніше Java і .NET. Все. Були ще рідкісні звірі на кшталт Access і PowerBuilder, але вони вміли використовувати COM / ActiveX. Таким чином, можна було достатньо легко "накрити" весь ринок засобів розробки.

Під web програмами ми розуміємо певний код, що виконується на веб сервері з метою взаємодії з користувачем через браузер або спеціалізовану клієнтську програму. І отут починається бардак.


Тільки в аспекті мов програмування ми маємо як вказані C++, Delphi, .NET і Java, так і такі динамічні мови як PHP, Perl, Python, JavaScript (node.js), Ruby, Scala, Groovy і пара ще більш екзотичних. Причому, наприклад Python'ів є два -- 2.5/2.7 і 3.х, котрі мають істотні розбіжності між собою і багато бібліотек не переписані ще під 3.x . PHP зараз вийшла версія 5.4, котра внесла чергові покращення і зміни (у нас на сервері використовується 5.2).

При цьому кожній мові програмування відповідає ще один чи кілька framework'ів, спеціалізованих для побудови тих чи інших типів сайтів.

До цього додаються кілька типів СУБД, а саме як SQL-based MySQL (в якості найбільш популярної web-based СУБД), так і noSQL СУБД (CouchDB, MongoDB).

Оскільки клієнтською частиною є зазвичай браузер, то єдиною на сьогодні клієнтською платформою є JavaScript з усіма його недоліками (котрих чимало). Розумною альтернативою був Flash, але він на сьогодні припинив розвиватись і Adobe переключилась на HTML5 і Flash.

Конструктивно серверний код web програм може виконуватись в кількох середовищах:

1) shared хостинг. Годиться для невеликих сайтів, зазвичай надаються доступ до MySQL (кількість баз даних обмежується) і PHP чи Python чи Ruby.

2) dedicated або virtual хостінг. Вся система (фізична або віртуальна) віддається в розпорядження орендаря, котрий має адмініструвати її.

3) PaaS, Platform as a Service. Це дуже цікава річ, про неї нижче.

Що таке клауди? Їх можна поділити на клауди зі збереження даних і клаудні платформи для запуску віртуальних машин.

Клауди зі збереження даних зазвичай побудовані на базі noSQL систем і пропонують сховище для пар "ім'я-значення", де значення (BLOB) може бути довільного розміру і може мати певні додаткові атрибути. До таких клаудів відносяться відомі Amazon S3, Microsoft Azure (точніше, Azure включає в себе сервіс зі збереження BLOB'ів). Доступ до таких клаудів і операції з ними здійснюються через HTTP-подібні RESTful APIs (це GET або POST запит по HTTP).

Цікавою штукою є клаудні платформи для запуску віртуальних машин. До них відноситься Amazon EC2 і деякі менш відомі. Фактично, це той же Virtual Hosting, але з можливістю робити репліки віртуальних машин та/або змінювати параметри цих машин (кількість пам'яті, bandwidth тощо). Самі віртуальні машини створюються клієнтом і завантажуються "в клауд". Віртуальні машини підлягають адмініструванню клієнтом. Фізичне розташування машин не має істотного значення, також вони можуть бути переміщені при необхідності.

Повертаємось до PaaS. Це покращений варіант клаудних платформ для запуску VM. В PaaS постачальник сам створює і адмініструє VM. Клієнт завантажує фактично своє програмне рішення (а не VM), зроблене під платформу. Тобто клієнту надається SDK, а клієнт пише свою програму із використанням цього SDK (одну - якщо програм кілька, то це незалежні програми, які мають взаємодіяти через публічні API, оскільки вони можуть виконуватись на різних віртуальних машинах в різних кінцях світу).

На сьогодні дві основні PaaS - це Google AppEngine і Microsoft Azure. Вони мають багато схожого, але і багато відмінностей.

Google пропонує створювати програми на Java або Python (або Go, але це їхня приватна мова програмування, котра набула певної популярності в 2009-му році, але faded away з тих пір) і використовувати мішанину сервісів від гугля, таких як якесь noSQL сховище для даних або механізми content retrieval'а.

Microsoft підійшли до питання з академічною прискіпливістю і створили потужну інфраструктуру сервісів, доступних для програм, що виконуються на платформі. Також, SDK доступні для .NET, Java, node.js і PHP (є ще якийсь generic SDK, з яким я не розбирався). Фізично це працює наступним чином: програма (кожна окрема) виконується на власній віртуальній машині під управлінням Win2008 Server + IIS (в випадку, якщо програма вимагає веб-сервера), але для нас це питання не є важливим.

Таким чином, можна сказати, що не існує якогось рекомендованого або загальноприйнятого способу розробляти ПЗ для веб програм. Також, на жаль, відсутня і лідуюча платформа, на яку могли б орієнтуватись виробники компонентів. З певною натяжкою можна сказати, що є популярним PHP, але тут ми натикаємось на інший нюанс - хоча PHP можна зв'язати з кодом на С/С++, не всі користувачі мають змогу зібрати або встановити С++ модуль під свою платформу.

З технічної сторони немає сенсу глибоко вивчати будь-яку вищеперераховану технологію, хоча варто почитати базово про кожну з них, щоб розуміти, що ми маємо на ринку. Решта (framework'и тощо) вивчається за наявності конкретних задач.

Є лише дві речі в випадку саме веб-програмування, які треба вивчати і знати.

По-перше, це JavaScript як мова і як технологія. Починався JavaScript досить просто, але зараз він суттєво ускладнився - там є об'єкти і класи, активно використовуються lambda функції і інший синтаксичний мотлох, малопридатний для читання і розуміння людиною (хоча це хвороба більшості сучасних динамічних мов, чиї автори змагались, хто заплутаніше систему позначень введе).

Друге - це атаки на веб-програми. На відміну від десктопних програм, веб-програми є джерелом для атак різного деструктивного елементу. І типів цих атак існує більше десятка, всі з використанням різних технік. І якою б мовою програмування чи технологією ви не користувались, протистояння таким атакам буде більш важливим, ніж всі інші аспекти розробки веб-програм.


When I look back upon my life
It's always with a sense of shame
Pet Shop Boys, "It's A Sin"

Власне, епіграф повністю відображає те, що я хотів написати в першому абзаці.

Питання: як це в психології називається? І як це лікується? Щось я з молодості пам'ятаю, що чи гештальт-терапія, чи транзакційний аналіз мають цим займатись

From Security is ... series 2
Колись писав, що ми вирощуємо Тибетський Молочний Гриб (по-простому - кефірний грибок) і п'ємо домашній кефір. Але оскільки смак його починає набридати, то треба було смак розбавити. Ну я і розбавив - грейпфрутовим соком в пропорції 1:1. П'ється набагато жвавіше. А якщо розбавляти вишневим, то має бути зовсім гарно.
Symantec - компания, убивающая ПО.

Для своего почтового ящика использую сервис usa.net в качестве mail collector'а. А он использует BrightMail для фильтрации спама и (это важно) вирусов. И работает, чертяка, просто отлично. Работал, до пятницы, когда вдруг перестал забирать почту. А заливать почту на них я не могу, т.к. эти альтернативно умные люди заблокировали мой почтовый сервер - он, видите ли, много спама шлет (ну да, в мой же почтовый ящик).

Это уже второй такой глюк usa.net, причем если в первом случае сапорт оперативно чего-то там у себя поправил, то сейчас уже трое суток ни бе ни ме ни кукареку (я пол-суботы пробивался через первую линию обороны сапорта, чтобы они передали мой запрос инженерам, имеющим доступ к логам POP3 коллектора).

Так вот, поскольку сам по себе brightmail работает хорошо, то я решил поставить его к нам на сервер. Ага, разогнался ...

1) триал доступен после плясок с бубном
2) цены неизвестны в принципе. Но поскольку сначала надо потриалить, то мы не выясняли
3) триал еще от 2010-го года. Виндовая инсталляция зачем-то захотела поставить tomcat server для Control Center'а (оригинально - я считал, что Control Center - это клиентское приложение).
4) документации нет. Вообще. в Start Menu пункт documentation открывает HTML файл, сгенерированный (как видно по его исходникам) из каких-то локальных документов, в котором говорится "у вас есть две опции - help и release notes, обе в PDF файлах". Ура! Где файлы? Х.з., но не на моем диске.
5) пытаюсь залогиниться в Control Center. Введите имя / пароль. КАКИЕ? Документации нет. admin/admin не подходят, локальная учетка тоже. Нажимаю Need Help Logging. открывается окно с текстом. "Если вы в Active Directory, введите имя/пароль. Если вы еще в какой-то заднице, тоже чего-то введите". А я ни там ни там, это отдельностоящий компьютер (standalone server во времена NT4 / Win2K назывался).

Ну на нет и суда нет (и туда тоже нет) - снес эту конструкцию, поскольку как ею пользоваться, все равно неизвестно.

Удивительно, как Symantec умудряется это продавать. И главное, что внутре у ней неонка действительно хороший продукт сидит, но вот как его выкопать из той кучи дерьма, в которую симантек его засунул?
  • Архів

    «   Грудень 2024   »
    Пн Вт Ср Чт Пт Сб Нд
                1
    2 3 4 5 6 7 8
    9 10 11 12 13 14 15
    16 17 18 19 20 21 22
    23 24 25 26 27 28 29
    30 31