• Хранение статических файлов на сервере

    @niko83
    Мне всегда хотелось попробвать подход с хранением кучи мелких файлов в одном файле, где нужная инфа вырывается по смещению + длинна. Такой подход используется на фэйсбук. Но что-то задач по этой части никогда не вырисовывалось.
    Позже оказалось, что можно сделать еще лучше. Изображения стали хранить в больших бинарных файлах (blob), предоставляя приложению информацию о том, в каком файле и с каким отступом (по сути, идентификатором) от начала расположена каждая фотография. Такой сервис в Facebook получил название Haystack и оказался в десять раз эффективнее «простого» подхода и в три раза эффективнее «оптимизированного»

    если захотите опробовать такой подход — отпишитесь о результатах
    Ответ написан
    2 комментария
  • Объясните странное поведение INSERT в mysql_query?

    KEKSOV
    @KEKSOV
    А часом у Вас на поле ident нет ли уникального индекса? А то Вы записываете три записи с одинаковым значением $idea_count — в вашем случае 3.

    Надеюсь приведенный фрагмент кода это просто тест, а не кусок из вашего проекта? В противном случае это одно большое отверстие в безопасности сайта ;) Переходите на использование mysqli и prepared выражений. Это резко повысит скорость выполнения запросов и избавит проект от большого числа проблем с безопасностью.
    Ответ написан
    4 комментария
  • Связь между температурой тела и испускаемым электромагнитным излучением?

    @vovagubin1987
    Всё просто. Все вещества состоят из атомов, а сложные и из молекул. У них есть структура и кроме того, они друг с другом взаимодействуют. Более того, есть заряд и магнитный момент и у тех и других. Температура в одном из своих определений есть мера энтропии, тобишь на русский, мера беспорядка, и ещё проще, абстрактной оценки движения составляющих в системе. Как известно, колебание молекулы, или кристалической решётки, имеющий заряд пораждает электромагнитное излучение. Соответственно, чем чаще колебания, тем больше частота, меньше длина, меньше период.
    Воот это и есть излучения, и длина волны(радиоизлучение, терагерцовое излучение, инфракрасное излучение, видимый свет, ультрафиолет, рентгеновское излучение, гамма излучение-в порядке возрастания частоты) зависят от температуры.
    Когда делают рентген, то не обязательно разогревать тело до плазмы. Можно что-то сильно разогнать(обычно это электроны) и резко их остановить. Тогда они отдадут энергию в излучение.
    Тело состоит из разных веществ. одни излучения хорошо пропускают, другие плохо, но другой вид излучения могут наоборот. Из-за того на экране и получается картинка. ренгеновское излучение частично поглотится(в том числе и уйдёт на разрушение днк в клетках, но механизмы коррекции с ним справятся), частично пройдёт сквозь(в зависимости от концентрации различных веществ в данном участке, которые зависят от типа клеток и их функционального состояния), частично отразится. Поглотившиеся излучение частично сразу может переизлучится, а остальное перейдёт в тепло. Но в виду кратковременности и малости(на современных приборах. А то на себе чувствовал, как влияет облучение на советских приборах) оно почти безвредно для организма.
    Абсолютно чёрное тело-это тело, которое поглощает любое излучение и не отражает никакого(но излучать может).
    Кроме того, есть ещё и спектр. Когда электрон на орбитали перескакивает на более низкую орбиту. он излучает.
    Ответ написан
    1 комментарий
  • Откуда берутся кавычки?

    Urvin
    @Urvin
    Вы точно смотрите по Ctrl+U, а не F12?
    Ответ написан
    1 комментарий
  • PHP — стоит ли использовать кэширование результатов выполнения функций

    Кэширование вообще несет в себе одну главную проблему: поддержка актуальности.

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

    Меморизация функций (кэширование результатов в зависимости от аргументов) требует выполнение двух ограничений:
    1. Функция всегда возвращает одинаковый результат при одинаковых аргументах (не зависит от состояния системы или этими изменениями можно пренебречь)
    2. Функция никогда не изменяет внутренние состояние системы (если функция была меморизирована, т.е. результат работы был сохранен в словарь, ключем которого является список аргументов, то дальнейшего вызова этой функции происходить не будет)

    Если эти ограничения выполняются, то возможна меморизация функции.

    Ответьте самостоятельно можете ли вы использовать кэш и меморизацию исходя из этих критериев.
    Ответ написан
    1 комментарий
  • WEB-программирование. Что выбрать и с чего начать?

    Mendel
    @Mendel
    PHP-developer
    ИМХО в вашем случае стоит начинать с пхп.
    Поскольку вы имеете опыт работы с более-менее строгими языками, то либерализм пхп не должен повредить детскую неокрепшую психику. Правда стоит таки включить E_STRICT сразу когда начнете писать.

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

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

    Итог: советую пхп, но сразу писать строго. Начните с одного из стандартов оформления кода…
    Ответ написан
    2 комментария
  • WEB-программирование. Что выбрать и с чего начать?

    pletinsky
    @pletinsky
    На мой взгляд базисные знания следующие:

    1) Клиентская верстка и стили (html, css). Можно пробежаться глазами хотя бы по теме. Почитать про правила верстки.
    2) Клиентская логика, работа с DOM (Javascript, Jquery). Важная тема — стоит уделить ей время.
    3) Теория распределенных приложений. — Веб приложения чаще всего являются распределенными. Поэтому стоит изучить архитектурные принципы распределенных приложений. API и т.д.
    4) Базы данных (SQL, etc.) — Конечно начать стоит с классического сиквела — но стоит посмотреть и шире — например на nosql решения.

    Далее стоит выбрать технологическую платформу. С вашим бэграундом вероятно стоит посмотреть в сторону Microsoft ASP.NET MVC. Это великолепное решение и погружение в обширный мир разработки в рамках решений MS. У них сейчас самые развитые языки программирования (C# 5.0), самые развитые инструментальные среды (MS Visual Studio), одна из самых совершенных виртуальных машин (.Net).
    Решение удобнее всего для серьезных и масштабных проектов, хотя и для небольших вполне подойдет.
    Следующий кандидат — Ruby on Rails. Это развитое решение с замечательным языком программирования и отличными каркасными решениями, заточенное именно под веб. Возможно лучше подойдет для небольших приложений — но и промышленные продукты без проблем потянет.
    Он также очень распространен.
    Ну и конечно PHP. Язык программирования данной технологической платформы отстает от требований к разработке больших решений — он скорее подходит для написания скриптов. Однако существует колоссальное количество каркасных решений для данной платформы, которые позволяют реализовывать даже приличного объема продукты. Кроме того данное решение наверное самое распространенное из всех.
    И оно потихоньку подтягивается до уровня платформ для разработки промышленных продуктов.
    Существует также множество других решений. Например огромный мир Java и решения на базе серверного Javascript.

    Скоп работ будет состоять из следующих частей:

    1) Клиентская часть (html, css, javascript). Тут вам понадобятся знания по верстке как раз и жаваскрипту. Также следует использовать различные базовые решения и фреймворки. Эта как раз та часть, где слишком глубокие знания (например использование чистого некроссбраузерного javascript) могут быть вредны и лучше все базировать на готовых платформах.
    Часто эта часть в web приложениях бывает больше чем хотелось бы.

    2) Серверная часть. Тут все определяется технологической платформой описанной в предыдущем абзаце. В веб приложениях как правило немного серверной логики — почти все можно заменить на внешние библиотеки. Но у разработчиков десктопных приложений всегда есть соблазн развивать именно эту часть потому что она им знакома — не поддавайтесь. Специфическая для проекта серверная логика нужна не очень часто. Если ее много — значить кто то увлекся велосипедами. Тоже касается разработок API и систем взаимодействия с внешними сервисами.

    3) Базы данных. Конечно обязательно! стоит использовать развитые ORM системы. То есть нужно их изучить под выбранную вами технологическую платформу. Ну и конечно базовые знания баз данных тут тоже очень понадобятся — сиквел, реляционная модель и все остальное.

    Дерзайте. Я за вас болею.
    Ответ написан
    Комментировать
  • Внешний SSD vs HDD?

    EugeneOZ
    @EugeneOZ
    В подарок — только SSD. Иначе какой же это подарок.
    Ответ написан
    Комментировать
  • Квадрокоптер-смертник

    @Vampiro
    Вы так рассуждаете, будто у вас С4 можно в Ашане купить, и только отсутствие квадрокоптеров до сих пор останавливало экстремистов! :)
    Ответ написан
    Комментировать
  • Аутентификация на 2 сайтах по ссылке?

    @dragan
    Вариант 1: Если мы хостите и оба сайта то авторизацию можно сделать на одном сайте, ну и авторизовывать на втором автоматически (пару стро ПХП кода… ну пусть пару десятков). При атворизации на втором сайте — редирект на первый, а дальше по накатанной.
    Вариант 2: Общая страница атворизации. Это как в первом варианте, но авторизация чисто визуально выглядит найтральной без принадлежности к первому или второму сайту.
    Есть есть вопросы, пишите в личку за саппортом.
    Ответ написан
    Комментировать
  • Почему космонавтика — оффтоп?

    InteractiveTechnology
    @InteractiveTechnology
    CEO, Interactive Technology Group (ITG)
    Вы пока пишите, всё же это намного интереснее жёлтой прессы, а так думаю со временем это пройдёт и на смену придёт что-то другое.
    Ответ написан
    Комментировать
  • Почему космонавтика — оффтоп?

    @1nd1go
    Это из Инфо
    Аудитория проекта — прогрессивно мыслящие люди, интересующиеся будущим IT-рынка в целом и интернет-экономики в частности.


    Просто эта тема — это про научно-популярное. Тут этой воды и без космонавтики много, и хотя кому-то нравится, кому-то нет, тематика сайта все же определена и лежит несколько в стороне от научно-популярного, хотя и в той же плоскости.
    Ответ написан
    4 комментария
  • БД под миллиарды записей и быстрые выборки

    @gleb_kudr
    PostgresQL.
    Ответ написан
    Комментировать
  • Продолжение статей про постройку квадрокоптера. Надо ли?

    POS_troi
    @POS_troi
    СадоМазо Админ, флудер, троль.
    Конечно продолжайте, тема интересная.
    Ответ написан
    Комментировать
  • Продолжение статей про постройку квадрокоптера. Надо ли?

    Zhbert
    @Zhbert
    Technical Writer, Linux user
    Да, думаю, стоит. Пиши, с радостью почитаю.
    Ответ написан
    Комментировать
  • Продолжение статей про постройку квадрокоптера. Надо ли?

    dutchakdev
    @dutchakdev
    Лично я люблю все тому подобное, так что я за.
    Ответ написан
    Комментировать
  • Каким образом управляют спутниками и зондами на огромных расстояниях?

    sevka_fedoroff
    @sevka_fedoroff
    При чем он стартовал в 1977-м году. Для меня это тоже все невообразимо.
    Ответ написан
    Комментировать
  • Автосигнализация не вскрываемая кодграббером?

    @egorinsk
    Наверно, разработчикам таких систем выгодно, чтобы машины угоняли и покупали новые. Других объяснений, при нынешнем то урвне развития технологии, я не вижу.
    Ответ написан
    Комментировать
  • Отличая Symfony 2 и Yii?

    С Yii плотно не работал, потому просто мнение:

    ORM в Symfony (Doctrine2), имхо, мощнее чем в Yii по определенению. DataMapper+UoW vs ActiveRecord. Плюс хранлище на основе SQL СУБД без особых проблем может быть заменено на что-то другое, MongoDB, например, также из коробки почти. Но, вероятно, DM несколько тормознутее AR за счёт широкого использования отражений. Решается путем создания кастомных репозиториев, где хоть напрямую SQL вызывайте, не пользуясь DBAL.

    Доступ в sf2 может быть основан на чём угодно, главное реализовать isGranted(). На основе ролей — из коробки.

    Вообще модульность и низкая связанность сильная сторона sf2 (не в последнюю очередь из-за DI где нужно и где не нужно :) ). Другие full-stack PHP фреймворки, что поверхностно изучал, этим похвастаться не могут. В sf2 жёсткие связи используются мало, почти всё конфигурируется: не нужны предлагаемые абстракции роутера — напишите свой класс хоть на switch case, хоть на C, главное нужный интерфейс реализуйте и строчку в конфиге поправьте (а можно и не править, но, имхо, не стоит).
    Ответ написан