Lift считается одним из самых сложных и в тоже время мощных web-фреймворков существующих на данный момент

А кем, простите, считается? Вот Play 2 например часть «официального» стека. И вобще я бы не доверял человеку, который о себе пишет, что он one of the top Scala developers (особенно глядя на код Lift, особенно ранний). View first мы уже видели в JSP/JSF, ASP/ASP.NET, да что там далеко ходить – в PHP (там кстати тоже всё можно делать очень быстро и лаконично и «безопасность» встроена прямо в язык (sic)).

Это не говоря уже о том, что код Lift идёт в разрез со всеми существующими coding guidelines и то, что они декларируют, как глубокое понимание идеологии языка, на самом деле является просто злоупотреблением мощными синтаксическими возможностями Скалы, от которого всячески отговаривают люди, которые действительно стоят во главе Scala-community. Результат: опытный Scala-разработчик смотрит на Lift-код и в принципе не понимает, что здесь происходит (это вроде как Java EE-разработчик и WebSphere-разработчик – это две большие разницы).

Поллак вечно рассказывает насколько у нас всё самое лучшее, самое крутое, все остальные ничего не понимают, а у меня сто лет опыта работы в индустрии (если что, до Скалы человек занимался тем, что торговал крутыми и сложными Excel-спредшытами). Самый лучший Комет? – По сравнению с тем, что уже сейчас (почти) есть в Play 2.1 это и рядом не стояло, я о Iteratee-based IO. Да и вобще люди велосипедов не изобретают, для асинхронного реквеста у вас обычный Akka-actor, а не что-то своё, не совместимое больше ни с чем.

Независимо от того какая методология испольщуется, если у вас есть проблема, то можно её решать, а можно ставить костыли/сметать мусор под ковёр. Ни одна методология не ставит своей целью писать плохой софт.

Макбук. Был бы республиканецем – был бы Делл.

Причём пару раз, на всякий случай.

Да, действительно это факт: после бума доткомов слово «стартап» стало подразумевать в первую очередь «технологический стартап». Хорошо это или плохо – вопрос сложный. На сегодняшний день от этого слова попахивает примерно так же, как от должностей вроде CEO/CTO в компании из <10 сотрудников.

Возвращаясь к этимологии: да вы хоть сосисочную откройте – это самый что ни на есть стартап. Причём среднестатистический «CEO» сосисочной значительно лучше понимает как строить бизнес, чем 90% нынешних «настоящих стартаперов» (тех самых, которые кричат фразы вроде «это сайт – это не стартап»).

Автор, за то, что вы донесли до людей новость, вам конечно плюс, но вот аналитик из вас никакой – что ж вы так переврали всё? «Похоже, что тяга Google к оптимизации затрат и закрытию непрофильных сервисов добралась и до GWT».

Скажу честно, перед этим Google I/O у многих закрадывались сомнения в будущем GWT, очередь при входе на техток по GWT была одной из самых длинных на конференции. Рекомендую поискать среди видео с Google I/O 2012 – многое станет на свои места.

Если кратко: показали 2.5 с набором очень интересных нововведений (по сравнению с невыразительным списком из 2.4) – видно, что люди этот год провели не зря. Рассказали о том, как и для чего Google использует GWT в собственных проектах. А также было анонсировано создание упомянутого «независимого комитета» – но только никто ничего никуда не «передавал», Google по прежнему будет принимать активное участие в разработке тулкита, но теперь это будет происходить не за закрытыми дверями, а будут руководствоваться мнением лидеров индустрии, использующих GWT и комьюнити – судьба проекта больше не будет определяться наличием либо отсутствием к нему интереса одной конкретной компании. Больше не нужно сидеть на пороховой бочке вроде и заранее обладать информацией о том, какие фичи планируются в будущих релизах.

Всё это несомненно пойдёт на пользу GWT, сделает его развитие намного более прозрачным, укрепит комьюнити – именно такое настроение осталось после этого тока в сумме с впечатлением от работы проделанной над 2.5. Но если преподносить это всё в таком свете, как это сделал автор поста, то действительно можно перевернуть всё с ног на голову, ещё один хороший урок о том, что всегда нужно черпать информацию из первоисточника.

Не сталкивался ни с 1, ни тем более с 2. Но даже если эти баги действительно имеют место, то в целом г+ значительно стабильнее, чем фейсбук и твиттер сейчас, не говоря уже про то, какими они были в первые годы.

Ваша формулировка аля «улучшенная джава» – это спорно мягко говоря. Groovy – динамический язык, как вы его не маринуйте со всеми Java 7 и invokedynamic, всё равно удар по производительности неизбежен, а вы говорите «улучшенная» – в итоге всё равно возвращаетесь к тому, что хотите type safety.

Короче говоря Scala вам в руки, а Groovy – это так, игрушки.

Фактически это тот же Galaxy Nexus, что продают Sprint и Verizon: 4.65-дюймовый Super AMOLED, 1.2 ГГц процессор с двумя ядрами, 1 Гб памяти и 5 Мп камера, Android 4.0.

Ну если уж «фактически», то это тот же Galaxy Nexus, который продают в UK и Европе. А Sprint и Verizon продают другой Nexus – помимо CDMA/LTE, он толще, там немного больше батарея и 32 гига памяти (против 16 в GSM варианте).

Также к этой же новости можно отнести тот факт, что теперь даже на нелоченый (GSM) Nexus в штатах можно поставить Google Wallet прямо из маркета и получить законные 10 баксов.

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

Subclasses cannot override private methods. Subclass overrides of public methods can’t even see, let alone call, the superclass’s private methods. Problematic for, say, test mocks.

На лицо непонимание разницы между private/protected :)

Для сомневающихся уточню, зарплаты в US пишутся конечно же до налога. Самые высокие налоги в Нью-Йорке и Калифорнии, но никаких 40-50% там нет — это же не Европа :)

Так с $7000 в New York City вы заплатите суммарно отчислений максимум 30% «всего лишь» (это ещё и включая базовую страховку — health+dental+vision). Опять же повторюсь — это максимум, в зависимости от вашей ситуации налог может быть и меньше, особенно если грамотно оптимизировать. Если готовы добираться до работы час, то можно найти нормальную студию до $1000/месяц (там будет нормальная сантехника, горячая вода, коднёр и деревянные полы), сравните с Москвой/Киевом.

Конечно же всё упирается в философию: идеология Python явно говорит о том, что должен быть только один путь достижения цели, тогда как Ruby напротив говорит о том, что должно быть несколько путей. Каждый выбирает то, что ему ближе, но все ведь понимают, что именно подход Python позволяет получить более поддерживаемый и чистый код в условиях современной коммерческой разработки.

Без «навязывания» определённого стиля никуда, если это не делается на уровне языка, то это делается путём различных coding style conventions/recommendations (ключевое слово «различных»). Часто «меньше» на практике выливается в «больше». И если индивидуальный разработчик может выбирать, то при работе в большой команде приходится задвинуть личные предпочтения подальше.

Тема очень раздута на пустом месте — как обычно вышел очередной гаджет от Apple и все хотят сделать себе на этом рекламу. Очень грамотно ситуацию описали тут: techcrunch.com/2012/03/20/dangerously-lukewarm/

Личные впечатления: в первый день через пару часов непрерывного использования (при подключении к USB) стало заметно, что девайс определённо греется сильнее, чем второй, он становится «тёплым» но уж никак не горячим (т.е. на комфортность использования это никак не влияет), говорить о каких-то ожёгах просто смешно — тема раздута из-за «ОБК» и синдрома «испорченого телефона» всякими ConsumerReports, которые просто хиты на сайте себе накручивают подобными публикациями.

(присоединяясь к предыдущим ораторам) И вобще, вот это утверждение «NP-полные задачи, то есть которые решаются за полиномиальное время на так называемых недетерминированных машинах Тьюринга» ещё надо доказать :)

Например когда нужен MVCC и репликация между удалёнными нодами через ненадёжные соединения. Ваш К.О.
Да и вобще, помимо «нужно» есть ещё «хочется» :)

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

На самом деле не выстрелило, потому что банально ДОРОГО. Как только приложение переходит в разряд highload готовимся к сумасшедшим счетам. Но это относится ко многим клаудам, тот же Heroku взять например. Только с другого облачного сервиса можно было спрыгнуть на свои сервера, если проект выстрелит, а в случае с GAE полный vendor lock-in, в основе которого своя БД.

Так что гуглу некуда деваться, надо дать людям то, что они хотят, конкуренты (с упомянутым Heroku во главе) сильно поджимают.

Не по теме Yii но всё же: что касается счётчиков, лучше промежуточные значения аггрегировать в кеше, например memcached и redis умеют делать атомарный инкремент.

Ваша новость — ни разу не новость. Эту фичу показывали ещё на f8 фиг знает когда. За это время 5 раз можно было сделать — это по поводу сговора между FB и VK, который разоблачили в комментах выше.

… особенно, если он четвёртый :)