lesha_penguin

Совет: если у вас нет действительно веских причин, по которым нужно именно ООО, то лучше не заморачивайтесь и работайте как ИП. Как ИП вы сможете практически все, в том числе принимать платежи на расчетный счет. Но отчестности и прочего гемороя у вас как у ИП будет в разы меньше чем в случае ООО/ЗАО.
Не говоря, уже о том, что ИП может пришедшие к нему деньги «просто положить себе в карман» (потому что «вы» в случае ИП «сами себе фирма»), а в случае ООО это не прокатит — поскольку «вы» отдельно, а «ООО» — отдельно.

Все равно никто ничего не скажет. Поэтому мои предположения:

1) Снижение нагрузки на DNS.
за: на каждое обращение к профилю юзера выполняется лишний ресолвинг. вносит задержки. лишняя нагрузка на сеть.
против: новость «как DNS лег под хабрэффектом» хорошо опубликовать первого апреля.

2) >9000 виртуальных хостов сильно огорчили сервер.
за: очень возможно, особенно если они были «брутально» прописаны в конфиге апача.
против: сильно сомневаюсь что оно так. Сотни-то хостинговых кампаний предлагают услуги виртуального хостинга, когда и поболее доменов висит на одном сервере, и чем хабр отличается? Да и высоконагруженные проекты с кучей поддоменов: тоже есть хорошие примеры, ЖеЖешечка например, так же, работает себе, и ничего!

3) Виртуальные поддомены вначале планировались для чего-то еще, типа возможности для хабраюзеров создать свой мини-сайт на хабре. Но потом решили так не делать. А сейчас просто «выпилили нахрен столетний рудимент» во время очередной итерации рефакторинга.
за: иногда код следует перебирать и архитектурно. куча заведомо мертвого кода в проекте — путь в никуда, как жизнь в городе-призраке!
против: только зачем? если рудимент не мешает, то святой принцип: работает-не трогай!

4) Поддомены *.habrahabr.ru хотят дать компаниям под корпоративные блоги (посолидней как-то ведь), а юзеров просто передвинут /users/username/.
за: очень даже возможно. Маркетингово совершенно нелогично когда «компания» имеет какую-то «домашнюю страничку» /companies/thecompany/ а «юзер» получает целый «домен».
против: а компаниям на это пофиг, у каждой из них есть свой корпоративный сайт.

5) Поддомены *.habrahabr.ru хотят отдать под тематические блоги. Каждая тематика-свой поддомен.
за: да, вообще-то логично! более логичнее, чем для юзеров!
против: а смысл?

6) Распределение нагрузки за счет наращивания количества обслуживающих серверов.
за: если определенные юзерские данные были связаны с определенными серверами, то логично.
против: все равно непонятно, если запрос проходит через rewrite то пофиг что домен что кусок пути.

7) Юзеры стали злоупотреблять пиаристыми поддоменами username.habrahabr.ru.
за: а что, *.habrahabr.ru — возможно попробовать как инструмент для раскрутки.
против: «малокалиберно» слишком. тянет на материал для новости на первое апреля.

8) Выкатывание какой-то принципиально новой фишки, где поддомен будет только мешать.
за: неизвестно что это за фишка, может поддомены и сильно будет мешать!
против: а неизвестно что это за фишка, может поддомены и не будут мешать;)

9) Хабр собирается выкатить пачкой сразу кучу хабра-сервисов. Логичное предположение, если ХабраСторадж — только начало, а завта планируется уже ХабраБлекджек.
за: habrastorage.habrahabr.ru для Хабрастораджа более правильно, чем постоянный риск «фишинг-батхертов» вида ha6past0rage.ru. Да и проще с одной кукой авторизации в одном домене.
против: ну, а если какой-то проект предусматирвает «столь тесную интеграцию с хабром», то почему бы не habrahabr.ru/projectname/?

Если вы чувствуете, что какой-то рассматриваемый вопрос это «killer feature», во первых малоизвестная, а во-вторых, позволяющая сьэкономить кому-то кучу времени и сил, то да, возможно, стоит постить. Кстати, лучший критерий-обоснование достаточности материяла статьи — это ваш личный опыт. «Как я сьэкономил неделю используя фичу xxxx» или «Как я снизил в три раза нагрузку на сервер засчет применения yyyyy».

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

Согласитесь, вам было бы намного приятнее и практичнее читать статью «Практическое использование расширений gcc для рефакторинга кода», неже ли просто куча разрозненных кусков «Малоизвестные фичи gcc» которые во первых, у кого было время сам уже вкурил в мануалах, а во вторых даже те кто вкурил врядли приходит в голову куда это приткнуть.

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

Для ваших нужд может подойти такой рецепт:
1) Есть такой замечательный файличек cidr_ru_block.txt доступен на Роснииросе, скачиваете свежий.
2) С нужной детализацией получаете регион (там три уровня Регион, Область, Город)
3) Загружаете в базу
4) Юзаете из пхп или из скриптов

Если данные невыровненны, то могут быть любые фокусы, атомарность не гарантируется.

Томозит ssh при работе или в момент коннекта?

Есть хитрый метод придумывания названия: Этот хороший вариант называется «мозговой штурм с соотвествующим вбросом».

«Вброс» нужен потому, что обычно сидеть и что-то придумывать у людей острого желания не возникает и народ обычно готов смирится с «назначенным сверху названием» и энтузиазма в этом деле (это by default, понимаете) и жгучего желания «креативить» не возникает. Что в данном случае плохо, потому что названии продукта должны принимать участие, те, кто над ним работает (точно также как родители придумывают имя своему ребенку).

Поэтому алгоритм:

Шаг 1) Собираете народ. Сообщаете: сечас мы тут собираемся придумать название для нашего программного продукта. Все как обычно молчат, ни у кого вариантов нет. Может кто-то что-то и вяло предложит «не блещущее».
Шаг 2) Вы смотрите на все это, выжидаете паузу. А потом делаете «вброс»: сообщаете «ну тогда если нет других вариантов, давайте назовем ******» (тут произносите любую взбредшую вам в голову охинею, чем бредовее тем лучше, а если она при этом неблагозвучна или вызывает пошлые ассоциации то это вообще замечательно). Главное при этом вовсе не та бредятина, которую вы предложите, а то, чтобы эта ваша реплика «нашла эмоциональный отклик в коллективе, ни кого не оставив равнодушным».
Шаг 3) Народ сразу «проснется» и переполошится: «нет, ну как же так!? как-то совсем пошло звучит! что других, нормальных вариантов нет? лучше уж назвать ее **** или ***** или ***** или *****». (хитрый план сработал: сразу же «проснувшийся» мозг народа переключается в креативное русло, а вы просто записываете шквал супер-креативных вариантов).
Шаг 4) Из этого потока креативных вариантов, просто выбирается тот который по душе всем.
Шаг 5) Регистрируете товарные знаки, логотипы, домены, и все прочее.
Шаг 6)…
Шаг 7) PROFIT

С точки зрения информ безопасности, самое первое с чем стоит определится это что мы защищаем и от кого/от чего. Без этого особого смысла нет вообще чего-то городить.
Второе: «информбезопасность» это всегда комплекс как технических так и огранизационных мер. Одно без другого смысла не имеет.

Вот вам список вопросов:

1) Вы хотите защитится от DBA? А зачем вы тогда держите у себя такого «сферического DBA в вакууме» которому вы не доверяете? Или у вас администрирование осуществляет сторонняя компания которой вы не доверяете? Тогда зачем такая ком пания? Так может «информбезопасность» начать с того, что подписать с ней соответствующий договор об ответственности за возможные утечки?

2) Вы хотите защитится от нерадивых программистов, которые херачат все направо и налево данные и пакеты на production базе? Вопрос правильный, только стоит его переформулировать так: у вас все программисты такие безотвественные школьники или есть один-два «ведущих разработчика», которые обладают достаточной квалификацией и ответственностью?

3) Вы хотите защитится от некорректных изменений/некорректных действий пользователей БД? А также от всяческих сломанных/слетевших с катушек внешних скриптов имеющих коннект к базе?

4) Вы хотите защититься от злых дядечек которые спят и видят как поиметь вашу базу и утянуть из нее все ваши суперсекретные данные?

А вот теперь, после вступительных вопросов я могу поделится своей Best Practice организацией безопасности (и надежности также) в Oracle.
* ответ на 1)й вопрос — чисто организационные меры
* отучаемся держать все данные в общей схеме-помойке.
* разделяем схемы на бекендные и фронтендные
* бекендные схемы содержат бизнес-данные и пакеты с бизнес-логикой их обработки
* бекендные схемы разделены по задачам и зонам отвественности — за каждую бекендную схему есть свой ответственный ведущий программист и никто туда без его ведома не лазит.
* фронтендные схемы таблиц c данными не содержат (вообще на них просто нет такого гранта как create table). они содержат только вью и пакеты которые преобразуют бизнес-логику «внешнего потребителя» во внутреннюю логику, адресуемую бекендным пакетам. Собственно фронтенд-вью и фронтенд-пакеты в том числе несут на себе задачи безопасности (такие как например не показывать например паспортные данные клиентов-физиков тому кому их показывать низя, не давая менять определенные поля в определенных документах тому кому не надо, показывать в фронтенд-вьюшке для менеджера только его клиентов а не всю клиентсткую базу, и прочее и прочее… то есть задач тут может решатся дофига-дофига-дофига, самое главное составить список этих решаемых задач).
* т.е. обратите внимание, на разделение «бизнес-логики» (бекенд-схемы) и «security-логики»(фронтенд-схемы).
* Все остальные пользователи и внешние скрипты ходят под своим отдельным логином (юзер с грантом только на коннект). Работают только с теми фронтенд-обьектами которые им явно грантованны. О структуре, огранизации и существовании чего-то в бекенд-схемах они вообще не догадываются, что дает сразу +100% к безопасности и надежности.

Много раз применял данную огранизацию в разных местах и всегда она себя оправдывала «на ура».

Насчет «новых технологий» дам несколько хороших советов (как человек, который уже многое успел повидать на своем веку).

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

Второе: Позволь, дам тебе несколько нестандартный взгляд на «новые технологии».

Попробуй, оглядись вокруг. Как грибы после дождя, из всех щелей валят «новые технологии». Что стоит за этим и чем грозит тебе лично?

Сразу видно, хитрые фирмы изобретут еще 100500 разных технологий, языков, фреймворков, парадигм и каждую из них они будут рекламировать как новую и революционную, готовую перевернуть мир (хотя я авторитетно скажу, что по крайней мере за последние 20 лет чего-то действительно принципиально нового придумано было чрезвычайно мало. компутеры стали меньше а программы больше. и все).
При этом каждую технологию подают исключительно как «серебрянную пулю», способную решить все текущие и будущие проблемы. А еще реклама давит на «чувство моды», выставляя всех кто не гонится за модой старомодными пердунами. И конечно, любая реклама тебе пытается внушить, что эта новая технология вот-вот вытеснит все остальные, и вам надо срочно все бросать и изучать пока не поздно чтобы не оказаться за бортом… да и вообще, есть еще over 9000 рекламных приемов.
Так вот — не верь рекламе — не забывай, реклама все врет. У любой технологии есть свои плюсы и минусы. Плюсы, даже весьма сомнительные, рекламно выставляются напоказ, а минусы, даже самые очевидные, тчательно маскируются и отрицаются.

Цель любой этой всей рекламы — чтобы такие как ты покупались на эту рекламу и сломя голову бежали «изучать новые технологии» (тратя на это свои силы, время и деньги). И самое главное, чтобы тащили когда нужно и даже когда совсем ненужно «продукты этих новых технологий» в свои проекты. А когда минусы станут очевидными, все обнаружат, что на технологию уже «подсели как на иглу» и просто так ее выпилить из проектов затруднительно. Знакомо?

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

Так вот, первый вопрос который ты должен себе задать: Твое время, силы и внимание, безвозвратные годы твоей жизни — оно что ничего не стоит, чтобы им так разбрасываться и просто дарить их кому-попало направо и налево? Наверное уж если вкладывать свое время так во что-то реально ценное! А вот что для тебя ценное — решать должен ты сам не позволяя никому в это влезать!

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

И все! Этого будет достаточно. Ты двигаешся к цели, и не даешь себя сбить с цели. И если вдруг ты видишь что какую-то технологию ты можешь применить применительно к своей цели (если оно оправдано и ты видишь что оно оправдано).

Заметь, применить не потому что «это модно», а потому что это отвечает твоим целям и задачам и ты хорошо взвесил, что трудозатраты окупятся! (Кстати, никогда не применяй что-то только потому что это «модно». Мода она ни к чему хорошему не приводит, она только порождает «жертвы моды».)

Помни главное: Изучая какую-то «новую технологию» ты тратишь свое время, силы, средства, внимание на продвижение этой технологии. Причем, сам, побывав в роли «пушечного мяса», от этой технологии ты скорее всего «получишь кукиш с маком», зато невозбранно сделав миллионные капиталы фирме-создателю этой технологии. Оно тебе надо? Подумай, дает или способна дать тебе эта «новая технология» хоть что-то ради чего, ты будешь ухлопывать ценные годы своей жизни на ее продвижение? Окупится ли? Вообще взаимовыгодное ли это сотрудничество для тебя?

P.S.: Кстати, если вообще не знаешь что учить — учи матчасть, учи основы, тренируй мышление, развивай мозг. Это всегда пригодится. Зная матчасть любую «новую технологию» ты запросто освоишь как только ты для себя решишь, что она тебе нужна.

P.P.S.: Короче, если по-простому, не будь хомячком, которого все стремятся сьесть на обед (т.е. не работай на продвижение ненужных тебе лично технологий).
Будь матерым волчарой, который сам сожрет кого угодно (пусть технологии работают на тебя, и любое взаимодействие с «новой технологией» для тебя сто раз просчитанное взаимовыгодное сотрудничество, только так).

Самый надежный способ: брать из /proc/ например, посмотрите, /proc/${pid}/io случайно не то, что вы ищете.

Если для того чтобы писать в логи, можете использовать более-менее штатные средства:
1) Глобальную таблицу const char* sys_errlist[];
2) Posix-рекомендуемую функцию strerror();
3) Ну и наконец «быстро и просто» ругнуться в stderr можно с помощью perror()

Понятно, что я вам счас сказал portable/compatible методы решения.

Сканеры штрих-кода (из тех, с которыми мне довелось работать) обычно работают в двух вариантах:
1) Эмуляция клавиатуры (те, кто подключаются через PS/2 или работают как USB HID)
2) Эмуляция COM-порта (те, которые соответственно втыкаются в компорт либо являются USB Serial Device)

Взаимодействие с первыми аналогично клавиатуре. В чем их плюс — возможность работы даже с тем софтом который не знает что такое «сканнер штрих-кода». Для программы это будет выглядеть полностью аналогично как если бы оператор набрал на клавиатуре артикул товара. (то есть полностью прозрачно для программ)
Соответственно, сериальные устройства для тех программ, которые знают что такое сканнер штрих-кода и умеют с ним работать.

Соответственно, вопрос. Вам для каких нужд? Если Вы хотите минимальными затратами организовать «рабочее место оператора» с взаимодействием через веб — то вариант с USB HID — это ваш вариант. Вы просто с помощью PHP рисуете форму, с полем, куда JS-ом выставляете фокус. Оператор «пикнув» сканнером штрихкода просто введет туда цифры. (И незабываем, какой еще ОГРОМНЫЙ плюс возникает, если штрихкод потерт и нечитается — оператор просто набивает артикул на клавиатуре в это поле.)

Вариант с Serial-подключением имеет плюсы лишь когда вы организуете выделенное узкозаточенное рабочее место.

Смотря для чего Вам это нужно? Именно от этого должно зависеть то что и как вы должны будете написать.

Если для рекламных целей — то формулировка будет одна, Если для написания лицензионного соглашения с пользователем — формулировка будет совершенно другая, Если для соглашения с дистрибуторами вашей программы и контента — то третья.

Потому что половина «правильных и грамотных» рекламных слоганов — охинея и безграмотность с юридической точки зрения. А от выражений типа «права на использование программного продукта, дейстсвующие с момента подписания договора-оферты» вызовут у юзеров реакцию «а вообще о чем это он говорил?!?!».

Причины психологические. Что такое хабракарма? По сути это «пузомерка». Но сама по себе «пузомерка», не несет негатива/позитива, негатив возникает, когда на какую-то пузомерку завязаны какие-то дискриминационные механизмы (явные или не явные).

А вот тут негатив возникает с обоих сторон. Как «снизу» так и «сверху».

Вот тебе примеры дискриминации на основании «обычных социальных пузомерок» какая у тебя зарплата, какая машина и какая жена:
Когда тебе говорят свысока, типа я в свои двадцать пять лет имею четыре фирмы, одна машина Бентли вторая Феррари, жена фотомодель и две стройные красивые любовницы, а чего добился ты, задрот, в свои сорок пять лет, живешь в комуналке, получаешь пятнадцать тысяч, на ржавый жигуль заработать не можешь, жена-алкоголичка и та от тебя ушла, неудачник! Ты на это все смотришь и говоришь, «ах ты такой-сякой буржуй, попадись ты мне в руки...»!
И наоборот. Ты достаточно хорошо зарабатываешь, работаешь, обеспечиваешь себя, и ругаешся каждый раз: Как же вы задолбали, гребанные нищеброды-попрошайки, не успел выйти из метро, уже плетуться к тебе с жалобным взглядом «у вас мелочи на пиво не будет», уроды, блин! Идите сами и заработайте!

Так с любой пузомеркой, как и вполне «материальной» типа денег, так и «виртуальной», например какой-нибудь ТИЦ и PR сайта, рейтинг на торрент-трекере, количество друзей в социальной сети,… список можно продолжать… та же самая хабракарма.

А когда тема такая скользкая, народ и сильно напрягается, когда о пузомерке происходит даже упонимание.

Вот например, я если вас спрошу, «Какая у Вас зарплата?»! Вы разве не напряжетесь? А зачем он спрашивает? Может чтобы помериться а потом посмеяться надо мной, сказав какое я ничтожество и неудачник? А может чтобы настучать в налоговую? А может у него преступные намерения? А может он еще что-то нехорошее задумал…

Есть зависимость чем более «дискриминационной» является пузомерка, тем больше даже упоминание о ней вызывает негатива! Увы, человек недалеко ушел от обезьян человеческая психология, она такая вещь!

Да, есть всякие NDA и прочие вещи. Но, давайте на это посмотрим с другой стороны.
Существует естественный процесс обмена и накопления опыта. Любой человек, а не только программист, использует какой-то опыт и наработки из предыдущих проектов и использует опыт и наработки текущего проекта в будущих. Это совершенно естественный процесс.

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

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

Это все равно что спрашивать «почему ваша жена ушла к другому, прихватив квартиру, машину и все сбережения на банковском счету в качестве трофея?». Так понятнее? Мотивация примерно одинаковая. Потому что вы сами сделали все для того, чтобы в другом месте человек чувствовал лучше чем с вами.

Это я говорю о именно Разработчиках с большой буквы (которые могут что-то реализовать), а не о «быдлокодерах» (которым даже если и получат в руки код, они все равно ничего с ним сделать не смогут, даже отладить до приемлемого уровня, не то что выйти с ним на рынок). Да и вообще, что у вас там такого секретного в коде, чего нет в других приложениях?

Короче мой ответ из трех пунтков: Грамотная

Порог вхождения может играть хоть какую-то ощутимую роль только в тех случаях когда он действительно различается в разы, например как если сравнивать Assembler и PHP.
А для вышеприведенных вами мейнстрим-языков порог вхождения примерно одинаков: Покажите, мне хотя бы одного C/C++ программиста, который бы сказал что никогда не смог бы осилить например php или python?

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