• Роспотребназдор отказался преследовать Apple за отсутствие зарядки у iPhone 12 из-за международного характера компании
    0

    В том и дело, что это дело каждого, кому что продавать и кому что покупать. Рынок как бы.

  • Роспотребназдор отказался преследовать Apple за отсутствие зарядки у iPhone 12 из-за международного характера компании
    +3

    Так не покупайте.

  • Новое приложение «Медузы». Почему Flutter?
    0

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

  • Количество и качество: как развиваются таск-трекеры в условиях конкуренции
    +1
    Да потому что Project это и есть Excel с пресетами таблиц и полей :) По крайней мере другого объяснения я не смог найти, при работе ощущение что ты как бы в экселе, но вроде бы и нет.
  • Как победить на собеседовании. Несколько крайне полезных советов для разработчиков
    +8
    Да ладно, в любой команде/компании всегда бывают жесткие запары. Необязательно из-за того что сотрудники некомпетентны. Сервера падают, случаются атаки на приложения или инфраструктуру в целом, клиенты внезапно осознают проблемы с требованиями — триггеров «аппокалипсиса» очень много может быть. И вот в таких, в идеале редких, ситуациях умение оперативно мобилизировать все свои скиллы очень важно.
  • Книга «От хранения данных к управлению информацией»
    0
    А электронные версии только PDF? или epub и прочие планируются в будущем?
  • В Японии протестируют возможность совершать покупки с использованием отпечатков пальцев
    0
    Это где такие ограничения?
  • Parse.com закрывается
    +3
    Вот вам и облачный бекэнд.
  • ORM или как забыть о проектировании БД
    0
    Это смотря с какой стороны посмотреть. Одна из целей абстрагирования в разработке ПО как раз и заключается в том, что бы особо не думать о том, что находится на нижних уровнях и как именно работает.
  • Долой оковы MongoDB
    +7
    Что значит на 2-3 уровнях?
    А насчет джойнов, то тут наверняка проблема в организации структуры данных. Джойны нужны в реляционных СУБД. В Монго денормализация является вполне нормальной практикой. Так что если нужны джойны, то стоит подумать над архитектурой БД.
  • Набор выживания для веб-разработчика под win*
    +3
    А почему бы демо-версии не выкладывать на тестовом сервере, который будет доступен клиенту откуда угодно без всяких установок софта на свой компьютер? Заодно и ездить меньше может быть придется ;)
  • Как и зачем я решил начать собственное дело
    +18
    А забирать потом накопленные деньги тоже можно?
  • АНБ отслеживает местоположение мобильных телефонов по всему миру
    +12
    Читаю я все эти новости про то, как АНБ то, АНБ сё и думаю — крутые чуваки эти АНБшники, такие системы замутить. И работать там технарями и аналитиками должно быть крайне интересно. Им в пору лекции на курсере по проектированию систем слежения выкладывать =)
  • Современные технологии проектирования ПО в контексте теории коммуникации и метода декомпозиции
    0
    Bullshit Bingo!
  • Еще один Tetris на JS (~30 «условных» строк)
    +7
    Горшочек не вари
  • Сравнение производительности различных систем шифрования под linux
    +2
    Хорошо бы графики
  • Роль тимлида: что остается менеджерам?
    +2
    Бизнес-аналитик это не предельный фен-шуй мечты. Просто он не всегда нужен, например если компания небольшая. То его роль выполнять все же лучше менеджеру проекта, а не тимлиду.
    Так то понятно, что из-за недостатка специалистов в большинстве случаев один человек занят в 2-3 направлениях.
  • Роль тимлида: что остается менеджерам?
    +2
    снятие запроса клиента
    и
    планирование и выпуск релизов

    Это вот уж точно не зона ответственности тимлида. Преобразовывать требования клиента в понятный список требований — это, как правило, задача либо бизнес-аналитика, либо менеджера проекта. А планирование релизов это вообще стратегическая задача. Тимлид отвечает чаще всего за тактику: разбить список требований на итерации, выделить задачи, проводить ревью кода, и держать в тонусе команду не давая ей прокрастинировать и еще не мало всяких вещей. Однако нужно понимать, что основная область работы тимлида — это его команда, он отвечает за общую эффективность.
    А то, что вы поместили в обязанности некоего менеджера. То это административные задачи в широком смысле, которые зачастую вообще имеют мало отношения к разработке проекта. И занимаются ими менеджеры по другим вопросам.
  • Архитектура интеллектуального Интернет-паука
    0
    Самым неприятным для реализации сейчас представляется модуль обновления и структура хранилища. Мне хочется, чтобы платформа сама позволяла хранить различные именованные сущности, причём с поддержкой версий.


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

    Во-первых как минимум на этапе сбора страниц оно удобно, потому что вы просто пихаете контент и заголовки в виде json-документа в коллекцию. То есть получается веб-страница = документ в монге.

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

    Конечно есть обратная сторона. Нужно описывать структуру документов отдельно, потому что со временем хаос начинается. Хотя можно строго изолирвать код, который работает с конкретным «типом» документов, тогда знание о конкретной структуре будет в одном месте.
  • Архитектура интеллектуального Интернет-паука
    +3
    У вас скорее всего возникнут проблемы с мониторингом на этапе реализации. На схеме он никак не связан с главными процессами, хотя может это проблема схемы)
    Разделение этапов загрузки и проверки не имеет особого смысла, и уж тем более такая их последовательность. Судя по описанному в статье, вы сначала пытаетесь загрузить данные, а потом узнать можно ли это сделать (например проверка на 404 ответ сервера). Думаю можно вынести обработку случаев, отличных от успешного получения данных. Но сами проверки совместить с модулем загрузки.

    Что касается нестандартных ситуаций, то их очень много. Но при этом получение страницы для установки куков принципиально не отличается от получения любой другой страницы.
    Поэтому я бы посоветовал придумать миханизм, который позволит управлять логикой поведения модуля загрузки. Обычно ситуации с капчами и куками выглядят как зависимость одной страницы от другой. И когда будет происходить загрузка, то система должна знать об этой зависимости и выполнять дополнительный запрос. Это немного портит идею того, что загружать за раз можно только одну сущность(страницу, файл, и тд). Но это упростит архитектуру и реализацию. Меньше точек нужно будет мониторить.

    Интересно как вы подойдете к реализации. Я подобную систему разрабатывал в одном из проектов,. там у меня схожие принципы применялись. Как раз вот готовлю статью на эту тему.

  • Роскомнадзор VS TitanPoker
    –3
    Вот и лудоманы подтянулись =)
  • MVC для андроид
    0
    Я под андроид пишу совсем недавно, но по-моему в самом фреймворке ОС предостаточно механизмов/инструментов для разделения этих трех уровней приложения. Разве что иногда нужно вынести некоторые вещи в общие классы. Зачем еще какой-то огород городить…
  • Знакомство с Apache Mahout
    +9
    А собственно что про саму библиотеку? Может быть стоило описать пример практического использования или реализации хотя бы простого варианта рекомендательной системы.
  • Элон Маск скоро представит проект новой системы пассажирских перевозок Hyperloop
    +37
    угу, из деревянных бочек и чугунных капсул
  • FeatureBranch
    0
    Думаю вам надо в сторону SOA копать: en.wikipedia.org/wiki/Service-oriented_architecture
  • FeatureBranch
    0
    Угу, похожая модель используется у нас. А за ссылочку спасибо)
  • FeatureBranch
    0
    Да, в транке работа практически не ведется, только исправляются ошибки, т.е. поддерживается его стабильность. А в качестве mainline используется ветка feature-testing, которая начинается от транка и используется для совместного тестирвания нового функционала.
    Однако мне кажется что держать функционал в mainline и контролировать его использование/неиспользование сложнее, чем просто собирать билды из feature-веток. Особенно если компоненты приложения слабосвязаны. Ну то есть можно наверное даже комбинировать подходы, просто вариант с ветками мне кажется более упорядоченым и очевидным. По крайней мере можно быстро посмотерть какие ветки слиты в билд и соотв. какие функции есть, а каких нет.
  • FeatureBranch
    +1
    Постоянная интеграция избавляет от проблем с мержами, но хорошо ли в основную ветку сливать незаконченный функционал?
    У нас в проекте по этой причине есть 2 дополнительные ветки, помимо trunk: для тестироавния багфиксов, которые нашлись в стабильной версии и для тестирования нового функционала. Вот с ними идет постоянная синхронизация. Но при этом в стабильную версию(trunk) сливаются только исправления.
    А из функциональных веток уже создаются билды и потом один из них становится следующей стабильной версией.
  • Двухнедельный обзор Google Glass: всё будет зависеть о цены
    +15
    Ну, у нас и за 1.5 купят
  • Говнокод или суперархитектура? Сначала говнокод, а потом эволюционный рефакторинг!
    0
    Хорошая статья и обсуждение в комментах)
    В текущем проекте после того как была «сформирована» архитектура, потом переформирована и снова и снова. Пришел к мысли о «проектировании через эксперимент». Когда важные архитектурные изменения, но не фундаментальные, вносятся в соответствии с реальными требованиями и поведением пользователей и системы под их воздействием.
  • GSA: Препарируем Google Search Appliance в виртуальной машине
    +3
    Продолжение будет? )
  • Анонсирована новая версия мобильной ОС Tizen: Tizen 2.0
    +8
    Думаю не совсем. У данной платформы по идее хорошие перспективы за счет более низкого порога вхождения из-за применяемых технологий. Все веб-разработчики смогут быстро адаптироваться к новой среде.
  • Как Google & Яндекс находят картинки
    +11
    Так а что тут удивительного. Меня как пользователя всегда раздражало то, что для просмотра картинок из результатов надо идти на какойто левый сайт. Пользователь, когда ищет изображения, хочет посмотреть изображения, а не сайт на котором они расположены. Все логично.
    А то что трафик упал, ну извините. Был полезный побочный эффект, теперь нету.
  • Очки Google запрещены в Украине
    +22
    Про гугловые очки там ничего не сказано. Както желтовато, да и про даты публикации уже написали выше.
  • Очередь сообщений (Message Queue)
    +2
    Да, побольше бы больше конкретики. Например почему сказали только об облачных решениях. Если приложение не использует какую-либо облачную платформу, но нужны очереди. Только ради этого не всегда стоит менять серверную инфраструктуру.
    Я так понял пост задумывался как мотиватор к использованию очередей сообщений в проектах. Тогда наверное стоило больше рассказать о подходах к построению архитектуры, основанной на очередях.
  • Пять причин быть управленцем
    +33
    Понеслась…
  • NASA Johnson Style — как нужно популяризировать науку
    +1
    Зануда
  • Качественно, быстро, недорого — разделяй и властвуй
    0
    Не удивительно, я переодически его перечитываю )
  • Standard PHP Library (SPL) — Часть 1: Структуры данных
    +8
    Я вот наверное злой какойто. Но блин, эта штука есть в php уже давно и поэтому меня немного поражают неокторые комментарии к статье. Статья то хорошая. Но какой блин нахрен ассемблер, причем он тут вообще? Причем тут списки продуктов? Ну то есть понятно, что оно так или иначе приведет либо к прикладной задаче, либо будет прослеживаться ряд аналогий. Но это же библиотека, которая позволяет использовать классические структуры данных в своих задачах и делать это удобно.
    Насчет использования — очереди собственно для очередей чего угодно: сообщения, задачи… ну многие другие ситуации часто являются подмножествами. FixedArray — очевидно для того, чтобы знать о размере занимаемой памяти. Хранилище объектов удобная штука когда нужно хранить набор объектов определенного типа + оно реализует ряд интерфейсов типа итератор, array access и других, что тоже полезно.
    Это же хорошие и удобные штуки, да еще и в ООП стиле.
  • Standard PHP Library (SPL) — Часть 1: Структуры данных
    +2
    Да вобщем-то давно оно уже есть ) Хотя хороший пост хотябы для популизации