- 1
- 2
foreach($arResult['ITEMS'] as $key => &$arItem) {
$priceRes2 = CIBlockElement::GetList(array(), array("IBLOCK_ID" => 34, "PROPERTY_PERIOD" => 1, "PROPERTY_PERIOD_TYPE" => 85, "PROPERTY_OBJECT_RELATION" => $arItem['ID']), false, false, array("NAME"));
Но это будет не по битриксовому.
Не удивлюсь, что это нарыто не в компоненте, а в шаблоне
Как же меня этот Bitrix доебал, но моя контора не хочет переходить на django или на какой-нибудь другой фреймворк. Почему? Да потому что несмотря на то, что нас зовут программистами, реально программированием занимается 1.5 человека, а ещё, блять, у нас так принято, что если ты программируешь, то на это смотрят как на потерянное время. Большинство "программистов", даже не могут что-то простое написать на том же php или js... Пиздец, блять. А начальники прибывают в иллюзиях, что кастомный интернет-магазин реально сделать за 20 рабочих дней параллельно с 2-3 другими такими же проектами.
Ну там - напишите примитивный графический редактор и все такое. Не знаю что там дают на пхп
Не я конечно понима, что сам не идеален, но всё-таки думаю, что моя фрустрация оправдана.
Учись, развивайся, расти, потом станешь нужен. Может быть
А на этой работе только деградируешь до... Хотя ты и так пхпшник на битриксе, куда уж там деградировать...
к 3_14darу обратись за литературой
вот еще https://www.youtube.com/watch?v=wOBSo09owqs&list=PLPErILqzuTQqXE IjjN6gwFzV1yRuwReR0
mailto:[email protected]
Или хотя бы так:
"3_14dar" <[email protected]>
Или так:
Собсно, это фейкомыльце, так что если думаешь что меня пиздец заспамят - мне похуй.
Ну это вполне обычное явление. У меня в работе ТЗ обычно представляет собой письмо от нач отдела с примерно следующим текстом. Есть человек который каждый день с 8:00 до 9:00 делает вот это. Задача сделать так, что бы он на это тратил меньше времени. Вот это считается ТЗ.
Но оно и хуй с ним, не меня пинают за долгие фиксы, а тимлидов.
он умеет из ящика таски тягать.
Далее приучить себя в системе контроле версий при коммитах ставить номер задачи
можно научить PHPstorm делать это самому. Уже будет порядок в коде и задачах.
Из любого бардака можно выбраться если поставить задачу.
Я уверен что каждый из разработчиков в вашей фирме хочет выбраться из бардака но не видит способа. Начните с себя организуйте ваше взаимодействие с начальством. Глядишь и остальные подтянутся.
чего языка нет?
Организуешь свою работу. Остальные видят как это круто и убеждаются в том что надо делать также. Для этого не нужно быть начальством. Не нужно быть просто анёбой как ты.
Васютка, много людей ты переубедил? С учетом того что у человека то ли неадекватное начальство, то ли просто работа не соответствует его ожиданиям.
Ну это уже сеньорско-миддловского уровня ТЗ, имхо... Джуниору очень тяжко будет с такими ТЗ.
Ну да. Или делает вид, что что-то заполняет, а сам во вконтактике сидит...
Это нормально. Откуда им знать, за сколько ты сделаешь? Это они должны у тебя спрашивать оценки по времени :)
"Как писать жопой на пхп за 2 недели для профессионалов" и "Букварь для профессионалов"
за кого ты их принимаешь
Что я для себя вынес
1 Читайте книжки от только тех людей, кто хоть как то участвовал в создании данной технологии
2 Читайте оригинал
Кто бы спорил :) Только потом грех жаловаться, что скучно и вообще мало платят...
Нет. Но будет шанс найти работу получше.
Или лучше смириться, забить на самообучение и всю жизнь проработать в этой говноконторе?
>Что-то мне показывает, что его работу можно замечательно выполнять, не зная как она работает и даже про О большое.
Как съесть слона? Бьёшь на более мелкие подзадачки, пока не сможешь на глаз прикинуть время и риски по каждой из них. Если срок выходит большой - продумываешь несколько чекпоинтов, на которых будешь показывать проект заказчику (а не один раз, когда всё время уже проебал). Ну и дальше пытаешься укладываться в срок по каждой подзадаче. Вот и вся теория ;)
если он там работает год, этого более чем достаточно, чтобы понимать границы возможностей сотрудника
думал, контекст о том, что ему на работе неудобные вопросы задают про сроки
И никогда не будет, если всегда будет ждать, пока ему сроки выставят...
А если цельным куском всю задачу делать - или профакапит сроки, или в прокрастинацию с перфекционизмом скатится. По себе знаю ;)
Ты через год работы не знал, хотя бы примерно, за сколько у тебя получается запилить форму или скриптик небольшой набросать?
Ему же там не поиск гугла и не ленту фейсбука писать...
В такие моменты очень хочется сказать - дяденька, я не настоящий программист, я просто диплом на свалке нашел
А все потому что в универах этому не учат. ООП дают черезжопное, паттерны, и учебник Кнута почитать, и все
Какой-то хаскельный мирок, где суть ясна, но все человеческие слова заменены на таинственные ORM, JSON, >>=, <*>, =()=.
А у нас не было паттернов.
а разные их пропорции дают еще куеву хучу метапаттернов, которые нам и вдалбливали - фабрики, фасады, мосты - ебаная архитектура!
А без практики - или начнёшь их лепить по поводу и без повода. Или вообще не поймёшь, нахуй они нужны.
До этого кодил, но нихуя не понимал
А после меня еще пару раз вштирило (спасибо хаскелю за это) и я вдруг понял что на самом деле эти паттерны - крайне неудачные штуки. Они преподносятся как кирпичики и которых можно что то слепить. а ведь на деле их них можно слепить только кучу хлама.
Неверная взаимосвязь дается - паттерны - все го лишь примеры, а не руководство к действию
+1. Просто стандартные формочки для говна, чтобы другим их легче было детектить и понимать.
Основные GRASP паттерны - низкая связаность (классы должны иметь как можно меньше связей с другими классами) и высокое зацепление (класс должен выполнять одну или несколько сходных функций, а не все подряд)
имхо, вот это и есть тру паттерны, а не всякие синглтоны да хранители
старое доброе юниксовое - пусть функция делает одну вещь. но делает ее хорошо
Причём всё это работает и для программ в целом, и для модулей, и для классов и даже просто для функций...
Кстати хаскель в этом плане неплохо мозги прочищает от ржавчины. Хоть и бесполезен сам по себе.
Главное ООПешникам такого не сказать, а то появится 30 паттернов для функций
GRASP, SOLID это больше "стиль кода", а шаблоны(паттерны) это "общепринятые названия" "строительных блоков" в ООП.
>низкая связаность (классы должны иметь как можно меньше связей с другими классами) и высокое зацепление (класс должен выполнять одну или несколько сходных функций, а не все подряд)
Но что это значит на живом коде студент не поймет. Если ему поставить простую задачу сделай класс для ведения логов приложения. Он тебе и сделает
класс Ddebug
метод wrtieLogToFile
метод writeLogToDb
метод writeLogToEmail
Я такое видел сто тысяч раз. Да студен помнит про низкую связанность Но что это значит не понимает. Преподы не могут рассказать потому что им это даже в голову не придет.
Хм. И трёх лет не прошло. (лень искать те твои комменты)
Я - паттерны говно!
3.14159265 - а я вот помню в 2010 году ты говорил... тут должна быть шутка про маразм и песок из жопы
"Новички не знают про паттерны, матерые знают и пользуются, гуру знают но не пользуются"
> или начнёшь их лепить по поводу и без повода. Или вообще не поймёшь
Да, со мной так и вышло, я их не понял. Кстати, чистые функции - тоже не понял. Зачем эти ограничения, когда можно в функции сразу и в файл записать, и глобальную переменную изменить!
Для меня всё это выглядело, как дурацкие запреты (кстати, http://bash.im/quote/438366)
Но, с другой стороны, нужно какое-то мягкое введение. "В прогромире есть такое. Вы не понимаете, но вот паттерн1, паттерн2, используются тогда-то". И у человека в голове рождается оглавление.
Кто-то считает, что нужно до всего дойти самому. Это полезно и естественно, но малоэффективно. Дойдёт человек до законов Ньютона, теорию относительности опишет, но зачем?
Кто-то - что нужно заучить теорию и приступать к практике. Проблемы здесь ясны.
По-хорошему, надо ознакомиться с оглавлением, затем с учётом оглавления продвигаться самому. И сам мыслишь, и не тратишь время на повторное выведение следствий.
Ну а после оглавления и практики можно вторым проходом полную теорию.
"Когда человек начинает учиться, он никогда не имеет четкого представления о препятствиях. Его цель расплывчата, его намерение неустойчиво. Он ожидает вознаграждения, которого никогда не получит, потому что еще не подозревает о предстоящих испытаниях.
Учение оказывается всегда не тем, чего от него ожидают. "
Я к тому, что составить оглавление можно только оглядываясь назад, когда ты уже что то знаешь
Поэтому оглавление нужно сначала. Можно запереть человека в тёмной комнате и попросить наткнуться на все углы и построить карту помещения, а можно походить в комнате с факелом, всё показать и пустить в соседнюю, неизведанную, когда он освоится в этой. В первом случае получим копию карты первой комнаты (и зачем она нам?), во втором - карту новой комнаты, которая уже окажется полезной.
1. Даём изучающему оглавление, рассказываем про подводные камни [он улавливает большой кусок оглавления]
2. Изучающий осваивается на практике
3. Даём изучающему полную теорию, он её осознаёт
4. Возможно, даём ещё практику (зависит от ситуации) [где-то тут он достраивает своё оглавление]
5. Выпускаем изучающего в неизведанный мир, где он что-то откроет.
Я нормально писал код на паскале, знал циклы, ветвления, рекурсию умел и имел уважение и даже ООП
Потом на 3 курсе у нас начались паттарны и препод принимал только на шарпе и у меня наступил такой интересный момент - я все делаю правильно по шаблонам, а при этом в голове какой то туман, непонятки почему, как и зачем. Никакой ясности
Потом я начал читать Рихтера и меня сильно ударило. Пришла ясность и понимание как это все устроено. И тогда я понял, что все делал верно, но по неверным причинам и выводам. Что мои знания были сильно сужены, не хватало глубины и какой-то точки, с которой можно было увидеть это все. осознать.
Проблема в том, что у меня всегда было оглавление, но я смог его осознать и прочувствовать, только через опыт и некоторое озарение
Знание оказалось совсем не таким, как я его представлял
без практики ты не понимаешь на какие вопросы отвечает теория
ты эти вопросы просто не задаешь
ну а без теории ты изобретаешь велосипеды
Будь проклят тот день, когда 25 человек выбрали меня project manager'ом на групповом проекте на пятом курсе... Там и время пришлось оценивать, чтобы не зафакапиться, и задачу разбивать, и архитектуру на верхнем уровне проектировать... И отвечать за проект своей жопой... А самая боль - делить заработанные за проект баллы между участниками...
Но нет, практически ориентированной it вышки у нас нету ;)
Вот в том и стёб, что дали один большой проект на всю группу. И дели его на подгруппы как хочешь... Это спарта ;)
Читеры. Нам тупо пачку баллов дали за проект. И дели как хочешь... Препод в расстановке оценок не участвовал (т.к. в общем-то и не в курсе был, кто что делал).
Делали пакет софта для автоматизации обучения. Что-то из этого вроде даже юзали потом...
> как такой ордой
Ну а какое КПД может быть у орды студентов? Так что в самый раз было.
Ну с горем-пополам разбили на 5 подсистем, спроектировали интерфейсы между ними. А там уже каждая группа свои куски писала. Так что не так страшен чёрт.
> заборостроительном
Слишком простая задача, раз в заборостроительном?
Простите, а это не вы живете в германии на пособие и компы домой с помойки носите?
Мне как-то похуй. Я вообще по специальности инженер-математик, а не айтишник.
То что я говорил когда в первый раз эту тему поднимал - у вас чтобы стать программистом все еще на математиков учатся?
Я был главным аналитиком и пиная бумажки отожрал 1/6 проектных денег
А я паре няшек поручил всю эту макулатуру писать, т.к. самому влом было заморачиваться с вордой :)
Написано русским языком - вот тут проверяет наличие этой херни, а потом делаем вот так - нееееееет, сука, в коде все через жопу и с двумя костылями.
А потом я переписал описание готового продукта и девочка, которая писала его до меня, обиделась(?!) и мы откатили все на место, что бы она не дулась.
Короче у меня остались крайне приятные воспоминания.
Не, я до такого уровня не опускался... Только интерфейсы между подсистемами, только форматы общих файлов, только хардкор... А дальше - ебитесь как больше нравится, лишь бы состыковалось потом... Ну и кусок сервера писал.
> крайне приятные воспоминания
Ну да - чай с няшками, пока доки писали :3
Вот час я могу хоть каждый день пить чай с няшками
Какие еще интерфейсы? Тыж манагер - по идее вообще должен был только всех пинать и мотивировать, ставить подписи да с заказчикам в гольф играть
А у нас 8 (если память не изменяет).
а я своих "няшек" просто поставил перед org-mode ^_^
план тренинга в таком суровом формате, как мне кажется, позволяет сразу прочувствовать предстоящий пиздец
Техникум что ли? :)
> Много проектов в 25 рыл ты делал?
А теперь посмотри на это с точки зрения остальных чуваков - они работали в командах по 5 человек и взаимодействовали с другими командами, работающими над другими кусками. Как думаешь, этот опыт такой же бесполезный, как руководство 25 студентами? :)
И как, помог тебе опыт работы в группе в 25 человек? Не полезнее были бы группы по 5-10 человек?
Ты вообще текст читаешь? Я же написал про группы по 5 человек, взаимодействующие между собой. Просто в целом это была одна большая система, а не 5 независимых друг от друга хуйнюшек. Ну борманду не повезло да, он в группе из 5 человек не поработал. Да и хуй с ним.
> помог тебе опыт
Ну да. Более-менее научился интерфейсы проектировать, бить задачу на подсистемы... Бесполезная хуйня? Ну ок.
Читаю, это у тебя пиздоглазие. Алсо тот пост ты написал после меня.
>И как, помог тебе опыт работы в группе в 25 человек? Не полезнее были бы группы по 5-10 человек?
Собсно, что тут с инженер-математиком на эту тему спорить.
А что, в рахе так хуёво?
а сам ты уже несколько лет пользуешься заброшенным поделием айтишника из Владивостока
и всё никак не соскочишь
Посетители ГК сплошь успешные программисты (одминкой можно работать везде)?
Кстати, вот хотел плюсануть d++, а тут внезапно
Application was halted by an exception.
Debug-mode is off.
Угу только один ты кусок бесполезной биомассы.