All streams
Search
Write a publication
Pull to refresh
35
0

User

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

И хоть я долгое время работал меркуриалом, я тоже за гит — популярность, опять же, сказывается.
Мы регулярно обсуждаем желания людей, но кроме как идей «а давайте попробуем!», никто внятного workflow не предложил.
Я даже на секунду подумал, что может быть с вашими людьми что-то не так, но у меня достаточный багаж таких вот обсуждений и предложений.

Тут собственно конфликт интересов — с одной стороны менеджмент все устраивает поэтому любые предложения воспринимаются вяло и «ну… мы подумаем» (следует читать как «я сейчас тебе не хочу говорить о том, что мне не нравится твоя идея, так что отвечу тебе лично через неделю когда ты придешь ко мне и спросишь „как там“, ну или забудешь).

С другой стороны разработчики, которые живут в своем, параллельном мире и им, зачастую хочется работать так, что бы оставаться актуальными на рынке труда (сотрудники, по крайней мере в ИТ, сидят не на привязи. И если им что-то не понравится, то свалить на другое, более вкусное местечко они могут и за неделю неспешных поисков — такова реальность*). Пошла повальная мода на XXX, то есть вероятность что на одном из таких вот обсуждений они начнут говорить о том, что хочется все таки заюзать ХХХ, даже толком еще не зная куда ее можно прикурить. А могут и начать что-то дельное советовать, но будете ли готовы вы.

И, кстати, еще такой вопрос, на который попробуйте, пожалуйста, ответить честно — а насколько вы действительно готовы что либо менять?

* есть отдельная категория людей которые никуда и никогда не сбегут (не будем говорить о тех, кто в доле) — это такие паразиты, которым плевать что делать, как делать и когда делать. Они как копались в своем говне, так и будут еще 10 лет копаться. Толку от них мало, но зато стабильно.
Долгое время использовали этот вокрфлоу, пока геймдевом занимался. Решает огромное количество проблем. Каждой фиче (а фичи иногда были такие, что приходилось перепиливать до четверти проекта) — свою ветку, потом в отдельной веточке (или в девелопмент ветке, тут зависит от сложности всего этого) собираем клевый билд (оставляя не у дел фичи незавершенные, который никому при этом не мешают), после уже в девелопмент, а там и в мастер попадает (т.е. на релиз). Оверхед на всякие мержи и бранчевания был минимальный, конфликты решались быстро и просто. Подобные вещи на svn я делал гораздо дольше и матерясь на всю комнату.

Как было до этого? Одна ветка багоправки, фичи — все туда, что не успелось к релизу — забивалось комментами и стабами, поэтому иногда могло отваливаться, подтупливать и вылезать наружу. Одним словом неприятная ситуация.
Я считаю, что плох тот кэш, благодаря которому, можно OOME словить. Хотя, думаю, в любом случае, до OOME далеко. До него еще будут несколько сборок мусора и тормоза такие (если хип у нас достаточно большой), что польза от данного кэша быстро убежит в минус бесконечности.

Одним словом я — за стабильность. Поэтому лучше кэш весь слить, нежели вообще сервак положить. Если слив кэша равносилен тому, что через несколько мгновений все ляжет и так — то надо думать как исправить эту ситуацию.
Так этож кэш. Тут можно и SoftReference заюзать, что бы oome не получть*
После этих изменений у меня кадабра исчезла из рсс. И заходил я на нее только пару пару раз, проверить жива ли.
Никто с этим не спорит. Думаю, что в боинге или аирбасе такое вряд ли допустимо, там на каждом уровне перепроверяют все раз по двадцать. Да и менеджера нет который подбегает и кричит: «Бросай все, тут надо вот заплить XXX еще вчера надо было, ты почему с работы вообще вовремя ушел?! Запиливай давай прямо сейчас».
Часами — это мало, многда надо что бы месяцами все работало
После 4-х лет писания кода на php, причем в основном не сайтиков, а всевозможных RIA и игровых проектов, я думаю я в теме что и как в этом стереотипном мире. Тем более что есть с чем сравнивать (и as3 плотненько смотрел и на руби заглядывался) — ушел в java.

Да, развивается очень быстро (по сравнению с некоторыми). Да, появляются новые клевые фишки (которые надо уметь правильно использовать(. Проблема то в другом — люди остаются те же, стандартная библиотека — та же. Ниша — ну куда она денется то.

Поэтому в этом мире еще долго на вопрос какой из фреймворков используете в работе, подавляющее количество ответов будет у того варианта, который называется «свой собственный», а на втором месте — «никакой, он мне не уперся никуда».

Ну значит они там что-то накосячили со своими измерениями.
Опять, же, 1.6 или 1.7? Сейчас, насколько я знаю, они на 1.7 и как раз с G1.
Покрытие, я уверяю вас, тут будет 100%. Тут дело в том, что данный код, подогнан под данный тест кейс и точка.

Уверяю вас, что в разработке случается такое, когда некоторые личности, несмотря на то, что на один и тот же юнит (класс\метод\строчку кода и т.д) могут быть десятки тест кейсов, все равно умудряются подогнать кусок кода для того, что бы он проходил тесты.

В итоге получаем 100500 тест кейсов, близкое к 100% покрытие кода, но открываешь некоторые методы и от ужасаешься от количества костылей. А некоторые еще и с комментариями // for blaBlabalaBlablabla test
К сожалению, сам не проверял, но люди использующие G1 в 1.6 на 8гб хипа говорил, что не так уж и быстрее нежели CMS. На 1.7 ситуация была куда лучше.
Единичный случай у меня был, когда CMS 12гб очищал как-то около одной минуты, к сожалению точных цифр не помню, но где-то в районе 50-70 секунд, и около 10 таки вычистил.

На 3-4гб значения были гораздо меньше, макс вроде бы около 3-х секунд было.
Разберем на примере: есть у нас какой-нибудь массив, и есть к нему тест кейс, что при добавлении нового элемента размер массива увеличивается на единицу, подгоняя его под тест можем дойти до такого кода:

def add(element) {
    size++;
}
<pre>

Тест кейс проходит на ура, но от реальности далековато.
есть функция foo, которая находится в глобальной области видимости, мы ее вызываем и сохраняем «ссылку» на ее в init (опустим тот момент, что this у нас может являться чем угодно в данный момент), внутри у нас имеется замыкание, внутри которого еще одно замыкание, изначальная функция foo у них является частью области видимости (по этому вопросу отсылаю к манам по замыканиям в js).

А делают у нас эти замыкания и вообще функция foo: они в самой глобальной области видимости (браузере это window) меняют ссылку на самих себя.

т.е. когда при первом вызове у нас window.foo, который является объектом Function смотрит на изначальную функцию. Мы вызываем эту функцию, которая внутри себя меняет ссылку на функцию-замыкание, которая видит все то, что есть в изначальной функции foo и делает тоже самое: меняет ссылку на свое замыкание, которое уже в свою очередь обращается к области видимости изначальной функции и меняет значение ссылки windows.foo на сохраненное в самом начале.

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

Именно. Народ бросается писать как видит, как удобно сейчас, даже не пытаясь понять как вообще этот язык устроен и работает изнутри (а он очень сильно отличается от того, к чему все привыкли) в итоге рождается такой п%#$ц, что заканчиваются любые слова.

Интересно, что движет людьми, когда у них вложенность одной функции увеличивается чуть ли не до 20, в которой выполняются 3-5 xhr-запроса с кучей коллебеков, которые дергают еще запросы, которые в свою очередь со своими колбеками… б$#@ остановите его кто-нибудь.
А не array_search ли, без strict параметра может возвращать откровенную ересь, потому что сработало замечательное приведение типов? И об этом надо помнить. Так же как и десятках других проблем связанных со стандартной библиотекой, которые описаны в документации и значит это не баг. Или они, наконец-таки сделали RecursiveDirectoryIterator из стандартной библиотеки рекурсивным?
Ох, не люблю я возвращаться к явоскрипту, который за последние два года видел раза три, не больше, но например можно сделать такую милую стейт-машину:

function foo() {
    var init = this.foo;
    console.log("foo");

    foo = function() {
        console.log("bar");

        foo = function() {
            console.log("foobar");
            foo = init;
        }
    }
}

foo();
foo();
foo();
foo();
foo();
foo();
foo();


В результате в консоле получим чередование foo, bar и foobar. Круто? Ну есть немного, юзабельно — еще как: похожий код, который как-то там внутри себя пересобирался и менял свое поведения в видел в продакшне. За что следует оторвать руки авторам подобных вещей — за то, что это да, работает, но допустим уже с setTimeout и setInterval будут проблемы, правда решающиеся врапером в виде function() { foo() } иначе застреваем в одном состоянии.

Можно еще пяток клевых вещей вспомнить, к примеру декорирование объектов налету или работа добавление методов к объекту, вызов коллбека с нужным скоупом…

Этож пхп-стайл, так что успокойтесь, там такое в порядке вещей.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity