Нужно ли каждый раз при изменении цены на услугу заново аппрувить её в биллинге?

В договоре будет указано, какие суммы (минимальная и максимальная) сервис может запрашивать, вот и все.

Обход кэширования js/css

При использовании ETag клиенту нужно каждый раз делать запрос к серверу, чтобы удостовериться, что данные актуальные. А при использовании «маразмов» — не нужно. Так что описанные выше «анахронизмы» лучше.

Покупка Б/У макбука на ebay

к отсутствию русских букв привыкаешь за неделю

Читалка или бумажная книга - что удобнее?

а киндлы в чехлах были или сами по себе, когда экран разбивался?

Обсуждения в ходе работы над небольшим проектом. как реализовать?

Почта с копиями всем участникам == гугл-группа. Ей, собственно, и пользуемся)

Посоветуйте лучшие практики PHP

Учит, например, не городить огород и не наворачивать «красивые» архитектуры, когда можно обойтись простой парой коротких функций) А типизация в питоне строже. Если честно, уже поднадоело мнение, что ООП — это панацея, и чем его больше, тем лучше. Я давно уже прочитал все эти книжки по паттернам, рефакторингу и тд. — Фаулер, банда четырех, Бек и др. Это замечательные книжки, в них много всего полезного написано и правильного, и они обязательны к прочтению для каждого программиста. Но этап восхищения прошел, теперь ясно, что бездумное и неоправданное применение ООП приводит к усложнению проектов, что ООП — далеко не единственный инструмент, и что если его можно не применять — его лучше и не применять. Книжки были написаны для языков Java и C++, тот же python (и другие функциональные динамические языки) гораздо гибче, многие паттерны из тех книжек в нем либо не нужны, либо реализуются средствами языка. В php же почему-то в последнее время тенденция тянуть как можно больше всего из Java и считать, что это круто, эдакое послание высшего разума низшему.

Посоветуйте лучшие практики PHP

Ну дак odmin4eg как был тем человеком, который писал код, так и остался. И считает, что на django/python он пишет код лучше.

У меня вот то же самое — я писал плохой код на php, а теперь пишу хороший на python/django. Человек 1, инструменты разные. Писать хороший код на python проще, чем хороший код на php, python учит писать хороший код, php постоянно провоцирует плохой код. Мне кажется, python way полезно освоить каждому программисту — и на том же php программист после этого будет писать код лучше (правда, писать на php вряд ли потом захочется).

Python. С чего начать учить?

Лучше уметь 2.х, чтобы навыки можно было использовать на практике.

Python 3.x сейчас имеет очень ограниченное применение (т.к. крайне мало библиотек под него, в.т.ч. нет большинства «больших» вроде twisted или django), и ему еще пара лет нужна (как минимум?), чтобы он мейнстримом стал.

Разъясните нюанс в наследовании класов в Python?

Переопределяйте не каждый раз, а в конструкторе. Это разновидность той же ситуации, что и mutable-значения по умолчанию для параметров функций:

def func(arr=[]):
    # если изменить arr, когда функция была вызвана без параметров, 
    # то значение по умолчанию поменяется для последующих вызовов

def func2(arr=None):
    arr = arr || []
    # а вот тут значение по умолчанию immutable и поэтому все ок

Удобный трединг в Javascript?

да, только там все-же через setTimeout реализовано, а не через postMessage, т.к. нужна кроссбраузерность.

Куда идти после php? Ruby или Python?

Да, согласен, плохо не станет. Сам много лет писал на компилируемых языках. В школе pascal, в институте C/C++, на первой работе программировал 3d графику (C++/OpenGL), на второй — реализовывал (на C++) различные алгоритмы сжатия изображений через вейвлет-преобразования. Софт для связи какого-то дефектоскопа с PC писал еще. Суммарно более 10 лет получается опыта программирования на компилируемых языках, до того как в веб ушел. Но просто вопрос в теме, как мне показалось, явно подразумевает выбор динамического языка для быстрой разработки, вероятно, под веб. C++/D и тд тут не в тему, т.к. скорости работы python/ruby в большинстве случаев хватает за глаза, а время разработки на них в разы меньше. Области применения разные. И вообще ни из чего не следует, что автор топика C++ не знает.

Куда идти после php? Ruby или Python?

А вы не почувствовали, что алгоритмы-то разные реализованы? Что в версии на python на обработку запускается количество процессов по числу ядер процессора? И что под это дело алгоритм переписан-распараллелен? Чтобы выжать побольше скорости на таких счетных задачах в отсутствие JIT? Что это синтетический код и так почти никогда не пишут? Нет, не почувствовали?

На картинку сегодня наткнулся по этому поводу: i.imgur.com/G7WyP.gif — хорошо иллюстрирует этот топик, где фанаты haskell ругают все нефункциональные языки, фанаты ruby ругают питон, а фанаты питона вроде меня ругают php.

Бр, повелся на троллинг.

Куда идти после php? Ruby или Python?

Лямбда — это анонимная функция. Т.е. функция, которая объявлена без имени. Она не обязательно должна применяться к каким-то там элементам множества, это просто функция без имени. В питоне такие функции можно объявлять только очень простыми, например

lambda x: x*2

В них не может быть ни циклов, ни каких-то операторов, только выражение. Это сознательное ограничение.
Лямбды используются для разной мелочи (указать направление сортировки, передать некий getter, который будет выдавать нужное поле объекта по самому объекту, например). Все более сложное объявляется явно через def. В js на лямбды таких ограничений нет. В обычных программах питоний подход работает отлично, т.к. он провоцирует на правильные действия — выделять сложные куски кода в отдельные элементы. В асинхронных это становится менее удобно (хотя тоже вполне неплохо).

Вот что я имею в виду:

// пример из мануала к node.js
var net = require('net');

net.createServer(function (socket) {
    socket.setEncoding("utf8");
    socket.write("Echo server\r\n");

    socket.on("data", function (data) {
        socket.write(data);
    });

    socket.on("end", function () {
        socket.end();
    });
}).listen(8124, "127.0.0.1");

vs

# гипотетическое переложение предыдущего примера на python
import net

def server(socket):
    socket.set_encoding("utf8")
    socket.write("Echo server\r\n")
     
    # мы не можем создавать обработчики прямо в параметрах add_callback, как было в js
    def on_data(data):
        socket.write(data)

    def on_end():
        socket.end()

    socket.add_callback("data", on_data)
    socket.add_callback("end", on_end)

net.create_server(server).listen(8124, "127.0.0.1");

тут net.create_server и socket.add_callback вполне можно было бы декораторами сделать, впрочем, и писать

@socket.callback("data")
def on_data(data)
    socket.write(data)

но это не отменяет того факта, что лямбды в js мощнее (как и того факта, что в python синтаксис, вобщем-то, приятнее и лаконичнее).

Куда идти после php? Ruby или Python?

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

Построчно переписать django не выйдет именно из-за различий в возможностях языков, как не вышло ни у кого рельсы переписать по-нормальному на php. Костыли будут торчать из всех щелей, начиная с отсутствия стандартной библиотеки. Будет также мешать отсутствие метаклассов и разных ФП-фич.

Хотя сейчас в php начали вроде элементы ФП вводить, это должно фреймворкам помочь.

Я, признаюсь, на php и php-фреймворки года 2 не смотрел детально, но статьи вроде той, что сейчас висит на главной (про тестирование контроллеров в symfony) реально пугают — какие-то жуткие xml-файлы и «Если ваши контроллеры реализуют интерфейс ContainerAware, вы получите DIC (dependency injection container) внедренный через метод ContainerAware::setContainer(), который вы можете использовать для доступа к любому сервису, который вы объявили в DIC». Это никак не назовешь стремлением к простоте, это подходы из java, а не стремление к быстрой разработке. В Java эти подходы используются для борьбы со сложностью проектов, причем большАя часть этой сложности обусловлена именно языком и его ограничениями, и то, что в php тащат эти подходы, немного настораживает (неужели там те же проблемы?).

Куда идти после php? Ruby или Python?

list comprehensions — очень удобные штуки, и они действительно убирают необходимость в filter и map в питоне, и в большой части лямбд (кстати, в js 1.7 они тоже есть, и когда-нибудь v8 это реализует). Но их никак нельзя использовать для коллбэков, что нас как раз и интересует при написании асинхронного кода. В питоне лямбда — это оператор, возвращающий какое-то значение, в js можно объявлять многострочные лямбды, делающие что угодно. В принципе, это тоже только синтаксический сахар, но удобно. А еще в js мощнее замыкания — внутренняя функция может менять захваченные переменные, в отличие от питона.

Ограничения в питоне — хорошие и логичные, они imho делают написание обычного кода проще и понятнее (никто не будет выпендриваться с функциональными фишками без необходимости, а воспользуется list comprehension или объявит коллбэк явно, отдельной функцией с именем, вместо того, чтоб создавать функцию прямо при передаче ее в параметры другой функции), но это все усложняет написание кода асинхронного. Не то чтобы кардинально усложняет, но все же.

Куда идти после php? Ruby или Python?

Ну вот научится, предположим, человек делать сложные вещи на php правильно. И так и не узнает, что сложными эти вещи являются только в php. Расширяйте кругозор, это точно стоит того. PHP как язык и как платформа для программирования гораздо хуже и python, и ruby.

Я, конечно, понимаю, что это может быть воспринято как понты, но все же. Буквально недавно была возможность сравнить (совершенно ненаучно, но очень явно). 2 команды делали одинаковый продукт (совершенно одинаковый), мы и еще одна. Мы писали на django и нас было 4 человека (из них я — единственный программист), они — на php и их было 15 человек (8 что-ли программистов). И при этом время разработки фич у нас оказывалось меньше, проработка деталей больше. Они постоянно не укладывались в сроки и выкатывали сырые продукты. Многое из того, что у нас сделано, той команде еще делать и делать. Фича, которая делалась у нас за 3-5 дней, ими была оценена в месяц (и до сих пор не реализована).

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

Вы пишете про сложность и правильный ООП. В том-то и суть, что на других платформах те же задачи решаются без сложностей, с ней не нужно бороться, и, кстати, даже тяжелая артиллерия ООП (которая, к слову, в ruby-python уж поправильней, чем в php) не всегда нужна. «Скилл работы с memcached» — чего там изучать-то, висит словарь в памяти, что может быть проще. Ясное дело, «silver bullet» не существует, и python — не silver bullet, а просто хороший инструмент со своими достоинствами и недостатками. Python и Ruby — давно мейнстрим, а не экзотика, фреймворки под них (да те же django и rails) — более матерые, проработанные и удобные, чем любой фреймворк на php. У php тоже есть технические плюсы, но они являются плюсами только на очень-очень простых проектах.

Куда идти после php? Ruby или Python?

да, и tornado есть, но
а) v8 в несколько раз быстрее любого интерпретатора python
б) все библиотеки для node написаны в асинхронном стиле. В python вся стандартная библиотека и большинство сторонних написаны в синхронном стиле. Для js просто не было наследия синхронных библиотек, там начали все с 0. В python это частично можно решить какими-нибудь хаками вроде манки-патчинга сокетов, но в node это все очень естественно — просто берешь и используешь все, все асинхронное;
в) лямбды и замыкания в js мощнее, чем в python, это помогает писать в асинхронном стиле более простой код

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

Куда идти после php? Ruby или Python?

Ну и зря не скажете. Т.к. на самом деле сильно быстрее и проще. Половина design patterns — это костыли для обхода ограничений языков вроде java или C++. Вместо того, чтобы использовать простую языковую конструкцию python или ruby, там нужно создавать дополнительный слой абстракции, писать какие-то классы, что неминуемо приводит к усложнению проекта и к замедлению его разработки. Чем больше кода, чем выше сложность проекта, тем медленнее его развивитие и тем сложнее его поддержка. А на языках вроде java кода *значительно* больше, и абстракций там вводить нужно *значительно* больше, чтоб проект мог развиваться.

Куда идти после php? Ruby или Python?

Знать язык != уметь на нем программировать. Программировать на python хороший программист на C++ научится правильно научится через полгода-год, когда выкинет всю C++-ную ерунду из головы. Сужу по себе ;)

Транспонирование таблицы SQL

какая разница, на чем решение, если это решение? да и про php в ответе Horse ни слова не было.