CKOPOBAPKuH

Вот что я подумал, когда прочитал:

> Разработанная собственная «CMS в зародыше с незафиксированным API» — имеется

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

> Опыт работы с высоконагруженными приложениями
> 80 страниц с секунду

WAT?

> Умение хранить в памяти весь проект вместе с его мельчайшими ньюансами

не работал с большими проектами

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

на любую задачу будет отвлекать тимлида или пма как минимум на пол-дня. а то и обоих сразу

В комментариях ругают, что не MVC, что плохое ООП, нет подготовленных запросов и дизайн сайта плохой. Всё это так, но:

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

Олимпиада — это долговременные инвестиции, изучение фреймворков/работа на дядю — кратковременные.

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

shootout.alioth.debian.org/

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

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

мне больше sql-решения нравятся, но можно я отвечу?

1. нет sql оверхеда. чем меньше и проще запрос — тем больше влияние этого оверхеда. при тысячах запросов на выборку по PK большая часть процессорного времени расходуется как раз на это. смотрите, например, бенчмарки mysql+handlersocket или mongodb в сравнении с обычным mysql

2. нет необходимости в «реляционности», «таблицах», «строгой типизации». у разных nosql решений есть разные возможности, например, какие-то из них ориентированы на хранение не-униформных данных (что в sql решается добавлением таблицы «ключ объекта — id атрибута — значение атрибута»), какие-то позволяют хранить графы (и делать специфичные для задач на графах выборки и операции). посмотрите, например, на git или svn. оба они используют свои базы данных, не-sqlные, для своих специфических целей.

а ещё, при тактовой частоте 3ГГц свет (и электромагнитное взаимодействие) успевает распространиться на расстояние 10 сантиметров.
но поскольку взаимодействие распространяется по процессору не напрямик, а по сложным траекториям, то максимально допустимый размер процессора будет не 70x70 mm, а меньше.
размер, например, Xeon'а — 42.5mm x 45mm. это в корпусе. размеры самой микросхемы — примерно 16x16mm. и это практически предел.

два варианта:
1. стартап-встречи
2. делаете пост не абстрактно «где найти разработчика», а конкретно. «есть проект, суть такова: (далее описание проекта — кратко). нужны такие вот разработчики: (кто нужен). если вы будете участвовать, вы получите (что разработчики получат)»

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

1) считаете количество пользователей без js
2) считаете средний доход на одного пользователя и перемножаете его на результат пункта 1.
3) считаете количество человеко-часов, необходимых для разработки no-js версии сайта
4) считаете стоимость этих человеко-часов
5) сравнить результат п. 4 с результатом п. 2. если в п. 2 цифра больше или они примерно равны, то делаете версию без js'а. если в п. 2 цифра меньше, чем в п. 4, то не делаете.

как Microsoft, так все кричат «патентные тролли» и «запатентовали всё на свете, пукнуть без спросу нельзя». а как сами что-то придумали, так «можно ли запатентовать? подскажите»

может быть, стоит подумать о realtime java?
habrahabr.ru/blogs/java/61658/

Windows Terminal Services
VNC
LogMeIn
X server forwarding

select u.user_id,u.username,u.password,u.user_type
,up1.profile_value as sex
,up2.profile_value as hobbie
,up3.profile_value as ещёчегото
FROM users as u
LEFT JOIN user_profiles as up1 ON up1.user_id=u.user_id AND up1.profile_key=«sex»
LEFT JOIN user_profiles as up2 ON up2.user_id=u.user_id AND up2.profile_key=«sex»
LEFT JOIN user_profiles as up3 ON up3.user_id=u.user_id AND up3.profile_key=«sex»

полагаю, что Total number of bytes read by this server from network учитывает общую длину пакетов. т.е. «SET keyname_312 vaaaalllluuuueeeeee», и может быть даже в этот показатель включается общий размер всех полученных пакетов с GET-командами.
отсюда и расхождение.