АртемЪ: тем не менее Вы его качаете добровольно и осознавая, что это действие незаконно. Если вдруг спиратенный фильм покажут по телевизору и Вы его посмотрите, то к Вам не будет никаких претензий, так как Вы не совершали никаких активных действий в отличии от телекомпании, которая совершила противозаконные действия.
Не хочу обидеть, но у Вас какая-то тактика овец, которых пастух гоняет куда захочет. Это позиция слабого: "усе украдено до нас". Не забывайте, что тот же рутрекер получает неслабые прибыли с рекламы. Т.е. условно говоря Вы покупаете украденную копию фильма. Я вообще не понимаю необходимости в этом - ПО почти всегда есть бесплатные аналоги, если аналога нет и ты работаешь только с этим ПО - купи его. Оно приносит тебе основной доход, т.е. какие-то люди тратили время на разработку ПО, которое теперь помогает тебе зарабатывать деньги. Кино - билет в кино стоит 200 - 350 рублей в моем городе. При этом я получаю качественную картинку и звук, а не смотрю камрипы или трачу кучу времени в поисках нормального качества. Тем более если не смотреть весь трешь, который выходит в прокат, а выбирать, то на кино у меня уходит максимум 1000 на семью в месяц. Музыка - 160 рублей в месяц подписка гугла и хоть заслушайся.
АртемЪ: т.е. Вы считаете, что Вася не прав и он вор. Двойные стандарты :)
Про Сноудена - я не читаю новости и телик не смотрю (максимум заголовки в яндексе смотрю когда открываю найти что-нибудь), но безусловно слышал, хоть и не в подробностях. Но от этого вором не стал, так как воровство - это активные действия, совершаемые с целью получения чужой собственности (определение можете найти в УК РФ). Вор Сноуден, при том гос масштаба и собственно из-за этого в США он и не возвращается.
АртемЪ: видите, у Вас сразу возник вопрос "кто ему покажет". Т.е. Вы явно не согласны с таким раскладом. А как пираты копируют фильм, который еще в прокат не вышел? Изменим пример. Вы работаете над проектом вдвоем с Васей. Проект закончен и Вы должны получить по 500 тысяч каждый. Вместо этого Вася копирует исходники и продает заказчику за 700к вместо миллиона, а Вас оставляет ни с чем. Опять же по Вашей логике все ок - Вася просто скопировал проект, а исходный вариант так и остался у Вас. Но я почти уверен, что первое же что Вы сделаете - обратитесь в суд и будете писать слезные вопросы на тостере.
АртемЪ: Плохой пример. Вы подменяете понятия, но вором Вас это не перестает делать. Посмотрите на ситуацию с другой стороны - Вам заказали проект на 1 млн рублей. Вы его сделали, а заказчик вместо оплаты тупо взял и скопировал его не оплатив ничего. По Вашей логике все законно - это не тот же проект, а его копия. А исходным проектом Вы также можете пользоваться.
Вы намешали всего. Во-первых, перепутали back-end и front-end (fornt - морда, которую видит пользователь, back - то, что скрывается за этой мордой), во-вторых, на андроиде - java, но возможны и варианты (вплоть до python, C++ и т.п., но это уже скорее исключения), на ios все таки не С++, а object c или swift (но опять же возможны менее популярные варианты). Под win phone - сам не в курсе.
Igor Karachentsev: gadfi абсолютно верно сказал. А какой интерес с этого человеку? Он выполняет то, что Вы от него хотите. Что Вам еще нужно? С моей точки зрения это более выгодная политика, так как у разработчика есть задача и он заинтересован выполнить ее быстрее и качественней, чтобы не править в будущем баги и иметь возможность отдохнуть на пару часов больше. Если же мы "копаем отсюда и до вечера", то разработчик не заинтересован в скорости\качестве, он отсиживает рабочие часы. Он знает, что даже если он закончит раньше, то все равно придется сидеть еще 2 часа до окончания рабочего дня.
astrotrain: с такой схемой Вам лучше использовать как раз таки асинхронность. В питоне есть куча всего под это дело (моя любимая либа - gevent, но вроде как стандарт уже asyncio). Но с многопоточностью это никак не связано. Многопточность в питоне хоть и создает несколько потоков, но переключение между ними происходит поочередно, т.е. как таковой параллельной работы нет. А это практически то же самое, что и в асинхронном подходе, только с накладными расходами на руление потоками. Ну и вообще вариант - по потоку на задачу - гиблый. Потоки довольно дорогие в плане ресурсов. Лучше использовать некий пулл если так хочется жонглировать потоками.
Добавлю еще, пожалуй, что с junior я бы не стал связываться на удаленке. Такой джуниор не сможет вырасти и стать самостоятельным за приемлемые сроки. На удаленную работу по сути подходят уже сформировавшиеся и самостоятельные разработчики, а не люди, которые приходят за опытом и знаниями (т.е. минимум от уровня Middle)
Сергей: если человек делает задачу за 8 часов, а реальный ей срок 1 час, то его стоит уволить до того, как от него станут зависеть дедлайны. И это несоответствие Вы уловите и без трекеров. gadfi: да, абсолютно верно. Если человек справляется с задачами, которые Вы ему ставите и успевает в приемлемые для Вас сроки, то Вас не должно волновать как он это делает: стоя на голове и за 2 часа или сидя 8 часов перед компьютером. Если, конечно, Вы не одна из тех организаций, которые больше увлекаются процессом не думаю о результате.
Т. е., повторюсь, я начинал собирать удаленную команду примерно с тем же настроем, что и Вы. Больше контроля, хочу, чтобы все были у меня на коротком поводке - не прокатит (по крайней мере у меня не прокатило и я пришел к другой схеме, которая показывает себя намного лучше). Вы нанимаете не грузчиков. Большинство нанимаемых людей будут как минимум не глупее Вас. Не стоит искать обезьянку, которую вы будете контролировать во всем. Найдите сотрудника, который будет делать все быстро и качественно и дайте ему максимум свободы. Это намного сложнее (и зачастую дороже), но приносит значительные плоды.
Roman Kitaev: google online: даже вроде 1.9.2 уже. Просто 1.8 это LTS (до апреля 2018 года), а 1.9 поддержка до апреля 2017 года. Но я бы все равно выбрал 1.9, там много полезных фич, которые в 1.8 приходилось велосепедить
тухлая это идея расписание. В нашей удаленной команде внедряли обязательные миттинги и другие крутые скрамм-штуки. В итоге из-за разницы часовых поясов в треть суток некоторым приходилось вставать в 6 утра, чтобы попасть на такой созвон на котором обсуждается фича совершенно не касающаяся половины команды. В итоге отказались от всей этой красивой, но бесполезной скрам мишуры (покеры, 1+1, миттинги) в пользу обычного человеческого подхода: нужно что-то узнать - звонишь\пишешь человеку и узнаешь. Если человека нет онлайн, а нужен срочно - мобильная связь. В итоге не тратим время на тупые созвоны из разряда "у всех ли все хорошо и что я сделал вчера и буду делать сегодня", каждый может работать в подходящем режиме (а иначе зачем еще удаленная работа? только из-за того, что модно?)
Alexander Litvinenko: нет не называют ) кеш - это некий буфер, который использует некие быстрые устройства чтения\записи. Ваш пример с HDD - там используют буфер для записи, куда пишутся данные, а затем, при накоплении эти данные сбрасываются уже на диск. Но никто не называет это оперативной памятью (если я неправ, то покажите ссылку, я честно попытался нагуглить, думал может отстал от жизни, но фраза "оперативная память жесткого диска" мне ничего не дала). Второе - данные процессов (чата, ноды и т.п.) живут все таки не в кеше, а в оперативной памяти. Да, если заняться философствованием, то можно сказать, что оперативная память это тоже своего рода кеш. Но тем не менее Вы мало того, что считаете себя специалистом, так еще и преподаете людям, поэтому нужно говорить правильно, а не как захочется. Ну и третье - от вопроса ТС мы уже давно ушли.
Alexander Litvinenko: если начать философствовать, то можно, конечно, сказать, что оперативная память это своего рода кеш. Но люди поопытнее нас с Вами все таки так ее не называют ) Т.е. если я захочу назвать оперативную память сосиской, то написав "чат и нода сидят по большей части на сосисках" вряд ли смогу называться профессионалом, пусть даже и приложив определенные усилия меня смогут понять окружающие.
Alexander Litvinenko: Да, кеш, это кеш. Но нода никак не сидит на кеше, так как термин кеш != термину оперативная память ) Поэтому тут 2 варианта - или Вы изначально неправильно употребили слово кеш, а сейчас отмазываетесь, или не понимаете вообще предметную область. Хотя ок, пусть будет по Вашем. В целом, чем больше людей Вы научите таким премудростям - тем более выгодно я буду смотреться на их фоне для работодателя.
Alexander Litvinenko: "обратил внимание еще на вид запросов в ответах, это запросы с нативными драйверами монги, но само собой так не пишут часто, чаще используют mongoose или аналоги."
ну если Вас спросят как выбрать всех пользователей с возрастом более 20 лет из базы, то Вы наверняка напишите что-то типа SELECT * FROM user WHERE age > 20, а не User.object.filter(age_gt=20). Так почему Вы предлагаете мне писать ответ используя ODM? Я написал как этот запрос выглядит через cli монги. А ТС сам разберется как ему этот запрос использовать - переложить на ODM или пулять напрямую в монгу.
Alexander Litvinenko: "а про прочее, сами осмыслите что написали, похоже сами недавно разобрались, теперь блесчете умениями. "
Ну не сказать, что недавно, но разобрался, что и Вам советую. Проблема в том, что Вы уже второй раз рассказываете то, о чем не имеете представления (по крайней мере второй раз я Вас вижу за этим занятием). Сначала пытались рассказать, что основное применение java это фронтэнд, теперь рассказываете, что "Чат в первую очередь сидит в кеше, как и по большей части все в ноде". А ведь Вы судя по профилю преподаете людям навыки веб разработки за 5000 гривен насколько я понял.
Объясняю на пальцах. У вас 10 пользователей. Заходит первый пользователь. Получает 500 сообщений из базы, кладет их в кеш. пишет сообщение. Кеш инвалидировался. Заходит второй пользователь, делает запрос в базу, кладет результат в кеш. Пишет первому пользователю "Привет". Кеш снова инвалидировался. И так до бесконечности. Нормальная ситуация для чата - общаться. А каждое новое сообщение инвалидирует кеш. Т.е. созданым кешом практически никто не успеет воспользоваться и Вы постоянно будете делать лишние телодвижения.
Далее. Если перестать быть занудой, то можно притвориться, что Вы говорите о некой структуре в памяти процесса, в которую при создании процесса будут загружаться все данные из базы, а далее в базу будет идти только инсерт + данные в процессе будут изменяться на лету (тогда можно даже понять что Вы имели ввиду, когда говорили про то, что кеш в ноде реализуется базовыми средствами). Ок, действительно здесь это выглядит идеальной схемой. Но если Вы преподаете людям, то научитесь использовать верные термины, чтобы потом не появлялись программисты, которые будут говорить, что "нода по большей части сидит в кеше". Это называется не кеш, а оперативная память. Кешом можно назвать сами данные, которые Вы будете хранить в этой структуре, но это не меняет того факта, что предложение "нода по большей части сидит в кеше" попахивает непониманием сути и является лишь попыткой повторить где-то выхваченные, но до конца не понятые знания.
Alexander Litvinenko: Вы видимо собираетесь делать чат, в котором сообщения никто не пишет? Зашел пользователь полезли в кеш взяли 500 последних сообщений, а уже давно другие пользователи написал новые 500 сообщений. Все таки заход пользоателя происходит куда реже, чем написание сообщений. В итоге кеш Ваш будет постоянно инвалидироваться и вместо обычного запроса в базу по ключу (id комнаты) Вы будете лезть в кеш, смотреть, что там ничего нет, лезть в базу, выбирать оттуда все нужное, класть в кеш, отдавать пользователю + еще при написании осуществлять инвалидацию. Для чата в общем случае я вижу необходимость хранить только данные зарегистрированных пользователей, существующих комнат и последних сообщений (и то я бы лучше хранил их просто в памяти, не страшно, если при рестарте потеряются). Из всего этого кешировать имеет смысл только список комнат и то аккуратно, так как выдавать все миллион комнат из кеша ничуть не лучше, чем выдавать миллион комнат из базы (все таки кеш применяется не там где много, а там где тяжелые запросы). Поэтому комнаты надо будет кешировать постранично, а тут опять проблема инвалидации, так как может добавиться новая комната, к примеру. Если комнаты сортируются по количеству пользователей, то могут измениться места и т.п. Т.е. кеш в чате вообще ни к месту в принципе. Даже если будет 1000 комнат - их проще выбирать из базы, так как проблем этот запрос много не создаст, а с кешированием\инвалидацией намаетесь. А 1000 комнат это уже приличное значение для чата. Алексей Ярков да, можно. db.users.find().limit(3);
Не хочу обидеть, но у Вас какая-то тактика овец, которых пастух гоняет куда захочет. Это позиция слабого: "усе украдено до нас". Не забывайте, что тот же рутрекер получает неслабые прибыли с рекламы. Т.е. условно говоря Вы покупаете украденную копию фильма. Я вообще не понимаю необходимости в этом - ПО почти всегда есть бесплатные аналоги, если аналога нет и ты работаешь только с этим ПО - купи его. Оно приносит тебе основной доход, т.е. какие-то люди тратили время на разработку ПО, которое теперь помогает тебе зарабатывать деньги. Кино - билет в кино стоит 200 - 350 рублей в моем городе. При этом я получаю качественную картинку и звук, а не смотрю камрипы или трачу кучу времени в поисках нормального качества. Тем более если не смотреть весь трешь, который выходит в прокат, а выбирать, то на кино у меня уходит максимум 1000 на семью в месяц. Музыка - 160 рублей в месяц подписка гугла и хоть заслушайся.