Максим Иванов
> но под них писали и будут писать, почему же на вебе так нельзя?
Не понял вопрос) Тормозят сильнее, поэтому пишут нативные мобильные приложения чаще, чем нативные десктопные.
> если вроде даже выпустили Atom и не покраснели?
Atom это хороший пример, а вот тому же GitKraken я бы предпочёл любой другой GUI к Гиту. Туда же GitBook Editor, туда же клиент Слаки (а они говорят Скайп плохой), который сжирает больше оперативы, чем моя IDE.
fedorov87 собственно, вам другие пишут примерно то же - заказчиком выступает Апворк, и когда вы выводите деньги, вы не переводите их со счёта Апворка на какой-то счёт в банке - Апворк просто напросто платит (!) вам, как будто вы для него выполнили какую-то работу. А клиент в свою очередь платит Апворку, как будто Апворк выполнил эту работу клиенту. В этом и суть посредничества фриланс-биржи.
fedorov87
> которое запрещает очень много что
ну, "много что" это довольно размыто, если уж вы утверждаете обратное, то привели бы выдержки из документов.
Насколько мне известно, заработать деньги за границей и там же их потратить - это одно, а ввозить, пусть и в виде перевода, деньги в страну и обналичивать их в рубли - совсем другое. Я пока не понимаю, почему Центральный банк РФ должен интересоваться переводами где-то там непонятно в какой стране. Оба аккаунта - и на Апворке и на Пэйонире можно открыть на абсолютно левое имя, ибо для этих организаций вы вообще непонятно кто. Если б они официально работали у нас в стране - было бы совсем другое дело, тогда б может и паспорт РФ бы требовался при расчётах. Вот как Пэйпал недавно начал интересоваться паспортными данными - чувствуете разницу?
> Апворк может и гарант, но деньги он перетаскивает, и счета клиентов и фрилансеров ведет. То что они перетаскиваются в электронном, а не в напечатнном виде, суть не меняет.
Я вам как раз и объясняю, что деньги он НЕ перетаскивает, и счета он НЕ ведёт. Счета в банках это счета в конкретной валюте, и деньги на счету в банке имеют конкретную ценность. Апворк - это не банк, деньги на счету в Апворке ценности не имеют. Деньги на счету в Апворке это примерно то же что деньги на счету у провайдера - вы можете ими оплатить услуги в будущем, но по факту эти деньги уже потрачены, не факт что вы даже сможете их вернуть. А раз не сможете вернуть, то это не деньги. С Апворком то же самое. Они могут заблокировать ваш аккаунт по своим каким-то подозрениям и у вас не будет достаточно законных оснований получить "деньги" с вашего "счёта".
Уточню, что может быть по законам каких-то других стран счёт Апворк действительно что-то значит, но это точно не про нас. Если б он что-то значил - он бы регулировался государством.
aol-nnov статью прочитал, как она относится к нашему разговору - понять не смог.
Я говорил о том, что для нас release often - это стабильный master, в который абы что не попадает, и с которого почти в любой момент можно выкатить релиз. Что мы и делаем в среднем по 2-3 раза в день. Но это не мешает отдельным разработчикам и даже командам делать долгие и тяжелые фичи.
> и изящность её решения просто поражают воображение!
ну сами сказали про линейность истории и минимум мёрж-коммитов) я потому вам SVN и предложил, там история линейна, зачем усложнять жизнь Git-ом) ну или Git используйте как SVN, коммитьте и пушьте в мастер, разницы особой нет с точки зрения модели ведения разработки.
Я тоже перед первым коммитом стараюсь делать фичебранч с максимально свежего мастера, но с учётом того что фичебранч будет тестироваться, скорее всего мастер уже успеет уйти вперёд, и мёрж-коммита физически не избежать.
Максим по соглашению (сам язык этого не требует) у событий должна быть сигнатура вида (object sender, EventArgs args), поэтому лучше всё-таки унаследоваться от EventArgs. Вы можете создать простейший класс:
class FormEventArgs : EventArgs
{
private readonly FormData formData;
public FormEventArgs(FormData formData)
{
this.formData = formData;
}
public FormData FormData
{
get { return formData; }
}
}
Максим саму структуру вы никак не приведёте, если по-нормальному, то создайте класс-наследник от EventArgs и поместите туда поле типа структуры. Впрочем, не совсем понятно зачем вам это)
aol-nnov Если у вас линейность истории, пользуйтесь SVN) Ну или если нужна стабильная ветка, то держите master и stable, зачем вам тогда фичебранчи вообще) Резко упадёт порог вхождения в процесс.
Фичи бывают разные. Когда вам, к примеру, нужно перелопатить сериализацию всех сохраняемых сущностей, коих может быть эдак 600 классов, а потом еще написать тесты, которые проверят вдоль и поперёк новый подход к сериализации и убедиться, что пользовательские данные не дай бог не испортятся насовсем - врядли вы это сделаете меньше чем за 2 месяца). Не говоря уже о том, что в этой же задаче может аукнуться старый технический долг. Ну или например вы переделываете дизайн сайта, а у вас одних less файлов на мегабайт, из которых вы половину переписали, не говоря уже о написанных с нуля контролах и виджетах. Треть нового дизайна не выкатишь, и половину тоже, даже если заработает, выглядеть будет не очень)).
aol-nnov и да, в чём проблема отката-то? Мёрж коммит откатывается и всё, это и есть "один коммит в мейнлайне" как вы выразились. Как можно "влить 100500" коммитов в "основную ветку", если есть мёрж-коммит, т.е. одна точка соединения мастера и фиче-ветки?
> но под них писали и будут писать, почему же на вебе так нельзя?
Не понял вопрос) Тормозят сильнее, поэтому пишут нативные мобильные приложения чаще, чем нативные десктопные.
> если вроде даже выпустили Atom и не покраснели?
Atom это хороший пример, а вот тому же GitKraken я бы предпочёл любой другой GUI к Гиту. Туда же GitBook Editor, туда же клиент Слаки (а они говорят Скайп плохой), который сжирает больше оперативы, чем моя IDE.