Архив рубрики ‘интернет’ Category

Jul
11
Личная встреча с заказчиками
1 балл2 балла3 балла4 балла5 баллов (стать первым, кто оценил!)
Loading ... Loading ...

Встречи с заказчикамиФрилансеры и удаленщики чаще всего стараются избегать прямых встреч с заказчиками.

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

(more…)

Feb
21
Установка FFmpeg в Linux
1 балл2 балла3 балла4 балла5 баллов (1 голоса, средний балл: 5 из 5)
Loading ... Loading ...

Upd. Продолжение — http://freeprogs.kiev.ua/2010/09/psevdostriming-video-i-poleznye-utility/

В частности речь пойдет про Debian Lenny, но это же самое вполне подойдет и для любого Linux, ровно как и для FreeBSD.

Немного предыстории: с самого начала видеохостинга у меня ffmpeg был просто втупую поставлен через менеджер пакетов — apt-get install ffmpeg .

Однако со временем я пришел к тому, что версия сильно устаревает (например текущая сборка в lenny датируется маем 2009 года — почти год назад), а версию из sid не всегда удается корректно собрать, и с этим надо что-то делать.

А что делать? Да взять и собрать себе ffmpeg из официального svn. Так и поступим. (more…)

Apr
13
Пару советов по созданию проектов
1 балл2 балла3 балла4 балла5 баллов (6 голоса, средний балл: 2.5 из 5)
Loading ... Loading ...

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

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

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

Итак, мой набор советов.

  1. Выключайте отображение ошибок на продакшене. Очень частая ошибка, избегайте ее, незачем давать пищу для размышлений для взломщиков. На экран пользователя не должна вообще отображаться какая-либо информация о серверной части, а тем более ошибки. Сделать это можно поместив в .htaccess строку php_flag display_errors Off
  2. Путь на файловой системе. Не используйте никогда директив по типу define (’PATH_ROOT’, ’/hosting/bla-bla/’) . Это глупая стратегия. Каждый раз править настройки при переносе проекта на другой сервер — абсурд. Используйте «магическую константу» __FILE__ , которая моментально вернет путь к текущему файлу (допустим конфигу), от которого можно получить нужный путь к корню проекта.
  3. Ядро проекта. Контроллеры, модели и прочее должно лежать как минимум на уровень выше, чем часть, доступная через веб-браузер. Хорошая стратегия строить приложение так — что директория ядра и директория, указанная в  DOCUMENT_ROOT — лежали на одном уровне (у меня эти папки обычно имеются как application и public). Данное разграничение призвано обезопасить проект от перезаписи файлов через уязвимость в проекте. Хорошей практикой также будет снять бит на запись от имени пользователя, под которым запущен веб-сервер.
  4. Загрузка файлов, изображений и т.д. Допустим, что все загружаемые файлы кладутся в папку uploads в папке public. Тогда первым делом лучше всего положить в папку uploads файлик .htaccess со следующей строкой — php_flag engine off — это поможет защититься от любителей залить бекдор через уязвимость в коде загрузки файлов на сервер. Это конечно слабая защита от загрузки бекдоров на других языках (например на перле), но «школьники» уже не пройдут. А лучше всего конечно делать безопасную загрузку, без уязвимостей. Но на всякий случай рекомендую подстраховаться таким образом — лишним не будет. Строка запрещает выполнение пхп-кода из данной папки и подпапок.
  5. Мультиязычность. Планируйте возможность мультиязычности еще на этапе проектирования и создания приложения, даже если это сейчас и не нужно. Это съекономит много сил и нервов, когда «вдруг» мультиязычность понадобиться, а в ядре ничего не заложено для этого. На подобные грабли в свое время наступил проект connect.ua, не повторяйте чужих ошибок
  6. Оптимизируйте все до того, как появятся нагрузки. Не стоит ждать, пока проект начнет тормозить под нагрузками и только тогда решать вопрос. Поставьте изначально байт-кешеры кода, например eAccelerator (или другие по вкусу), настройте кеширование на стороне клиента (хорошие советы в этом плане можно найти на webo.in) и на сервере. Это даст существенный прирост производительности (иногда порядка 300 и более процентов), что существенно снизит нагрузки и повысит скорость загрузки страниц у пользователей.
  7. Настройте оповещение об измененных файлах за сутки. Я обычно это делаю через помещение в крон строки: 0       0       *       *       *       find /path/to/public/dir -mtime 0 | mailx -s «report :) » my@mail.com > /dev/null 2>&1 , после этого мне раз в сутки приходит список измененных файлов в директории, анализируя который можно понять, все ли хорошо. Тоже самое можно настроить и для ядра проекта. Данный отчет однажды спас меня, когда произошел взлом одного из моих проектов и по всей фс были накиданы бекдоры — через эти списки мне легко удалось всех их удалить, без поднятия проекта из бекапа. Лично для меня — это теперь незаменимая вещь, лог которой я просматриваю раз в сутки обязательно на наличие подозрительных изменений.
  8. Всю разработку ведите на SVN и на дев-сервере. Не стоит делать правок «наживо» на продакшене. Я считаю оптимальным — настроить SVN так, чтобы при комите данные сразу попадали на дев-сервер, где можно еще раз протестировать сделанные изменения. Это очень удобно для разработки и тестирования. Как правило дев-сервер может быть отдельной машиной, но также это может быть и виртуал-хост на той же машине, где и продакшн. Правда последний вариант не рекомендую, т.к. при тестировании могут быть разные ситуации, вплоть до зацикливания кода и нехорошо, когда это влияет на работу текущих пользователей.

Если еще что-то вспомню важное — допишу.

Успехов!

Mar
12
Стартап с нулевыми вложениями – миф?
1 балл2 балла3 балла4 балла5 баллов (1 голоса, средний балл: 5 из 5)
Loading ... Loading ...

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

Почти каждый день на просторах СНГ появляется по одному или нескольку новых стартапов (при этом чаще всего -  по типу «социальная сеть»). Очень малая часть из этих проектов выживает в первые полгода, еще меньшая часть доходит до монетизации (чаще всего создатели еще изначально не знаю, за счет чего будут монетизироваться). (more…)

Feb
01
Подход «Getting Real» при создании веб-приложений
1 балл2 балла3 балла4 балла5 баллов (1 голоса, средний балл: 5 из 5)
Loading ... Loading ...

Getting RealДумаю сегодня мало кто не знает (или хотя бы не слышал) про такую компанию, как 37signals.

А для тех кто не знает — это компания из Чикаго, которая прославилась на весь мир своими продуктами (BaseCamp, Ta-Da list, Campfire, Ruby On Rails и другими) и политикой создания своих продуктов.

На сегодняшний день их проектами пользуются более 1 миллиона человек по всему миру.

В чем же их успех, спросите вы. Ответ довольно простой на самом деле.

Ознакомившись с материалом их книги (которую кстати рекомендую к прочтению)  стает понятно, что компания пропагандирует принцип «KISS» (Keep It Simple, Stupid! — что дословно означает «делай проще, дурень!»), который они «обозвали» «Getting Real».

(more…)