|
Флудильня Разговоры на любые темы. Мы устаем постоянно работать. Иногда надо где-то немного отдохнуть. Пожалуйста, не надо здесь устраивать бардак. |
|
Опции темы | Поиск в этой теме | Опции просмотра |
27.08.2014, 10:42 | #1 |
WowCore Dev
Регистрация: 31.03.2010
Сообщений: 468
Сказал(а) спасибо: 73
Поблагодарили 106 раз(а) в 70 сообщениях
|
Delphi Tour
нет ни у кого желания посетить дельфи тур 16го сентября в москве?
http://delphitour.ru/ так то я понимаю, что большинству из вас это безтолково, дельфи какая то, блаблабла, но мы ж туда не за этим едем я был в феврале в казани, вот намереваюсь и в этот раз. |
27.08.2014, 13:00 | #3 |
WowCore Dev
Регистрация: 31.03.2010
Сообщений: 468
Сказал(а) спасибо: 73
Поблагодарили 106 раз(а) в 70 сообщениях
|
а мне нравится студия ихняя, не испытываю никаких проблем с ней, все что мне нужно работает. правда и нужно мне совсем не много. функционал студии все таки сильно развился по сравнению с 7, не будем кидаться в крайности так же можно сказать, что XP/vista/7 наклепанные версии, а функционал как был NT так и остался. ну и синтаксис языка сильно развился так же.
ложная подсветка ошибок - замечал, да. лечится как обычно перезагрузкой студии. интелисайн и прочие аддоны не пользую. отладчик не пользую, у меня с отладчиками вообще все плохо, не даются они мне. у меня свои отладочные методы. самое главное это компилятор стал нормальный более менее, остальное мне по боку. плюс единая база кода под разные платформы. мне нравится, что на выходе нативный код под платформу, а не байткод под машину. я сторонник нативного кода, что бы использовать возможности ОС на максимум. "кроссплатформенный" код - это все кроилово, ни туда ни сюда. имхо, ессно. но речь не об этом ваще то, а о том, что б собрацца, познакомицца, обсудить дела наши серверные, все это дружно слить или наоборот. в общем развеяться от дел насущных. мне в феврале помогло |
27.08.2014, 13:41 | #4 |
RuDB Dev
Регистрация: 01.02.2010
Адрес: localhost
Сообщений: 592
Сказал(а) спасибо: 323
Поблагодарили 283 раз(а) в 122 сообщениях
Записей в дневнике: 2
|
Возможно моя нелюбовь к Дельфи возникла из-за того проекта над которым пришлось работать.
Представьте себе коммерческое приложение которое состоит из кучи форм, в и в основном это какая-то отчетность + формы редактирования. Так вот все эти формы вызываются из основной формы "MAIN.pas" и в этом же юните реализованы все методы выборки для каждой формы. и эти 72к строк кода в "MAIN.pas" кажется и сделали свое дело. + секция var с около 1к переменных в 1 месте. В итоге никакой масштабируемости, костыль на костыле, постоянно падающая студия (в день 2-3 раза именно на этом проэкте). + Дырявые компоненты, из-за которых куча утечек памяти. И да, больше всего убивает 1 баг: У нас есть "чувак" который работает с увеличеным шрифтом, так вот после него постоянно приходится править формы, так как после компиляции они выглядят ужасно. Чет я завел холивар на форуме и параллельно в кабинете у нас |
27.08.2014, 13:53 | #5 |
WowCore Dev
Регистрация: 31.03.2010
Сообщений: 468
Сказал(а) спасибо: 73
Поблагодарили 106 раз(а) в 70 сообщениях
|
ну чото да, намешаны мухи с котлетами.
ну да, скорее всего нелюбовь изза таких вот проектов. но объективно говоря язык сам по себе то тут не при чем на моей практике в Ericsson подобного кода масса, только на C и Erlang. понятно же, что это говнокод производства "главный говнокодер & поцаны", а не язык С такой. по работе в Nortel/Avaya мне приходилось работать с джавой в NetBeans. блин, клевый IDE, но он меня бесит своими "нестандартными" хоткеями и самодеятельностью в процессе редактирования. но видно же, что нетбинс правильный. просто не мое, я к другому привык. поддержка проектов - худшая работа, что можно придумать. дизайн все таки по приятней. особенно если сразу делать все как следует. холивар холивару рознь, истина рождается в споре. конечно, если он аргументированный, так что порой это бывает полезно |
27.08.2014, 14:26 | #6 |
RuDB Dev
Регистрация: 01.02.2010
Адрес: localhost
Сообщений: 592
Сказал(а) спасибо: 323
Поблагодарили 283 раз(а) в 122 сообщениях
Записей в дневнике: 2
|
Щас расскажу прикол:
В общем у нас очень много мест где идет выгрузка данных в List<T> где T это некий ДатаКонтракт для вебсервисов (Класс и куча свойств). Я для этого накатал для себя вот такой вот хелпер (на идею натолкнул LordJZ в проекте https://github.com/LordJZ/DBFilesClient.NET), который формирует метод для заполнения свойств значениями из DBReader: Я его запостил только в своем проекте. Через некоторое время ко мне приходит "насяйникЭ" и говорит что это сильно бьет по производительности, и надо просто написать код, который проверяет поле на IsNull и присваивает свойству. Я спросил покажите мне в каком месте оно бьет по производительности. На что тот просто показывает этот класс, говорит что слишком долго будет выполнятся этот код для каждой строчки. Я начал объяснять что этот код будет выполнено всего 1 раз при первом обращении с указанным типом, но он не поверил потребовал доказательств и т. п. Потом пошло куча обучений и поучений. И было им принято решение исключить этот код из проекта. Я сказал что ок, и ничего не исключал. Прошло время и он опять пришел и спросил про тот класс хелпер, и говорит хочет попробовать сам им попользоваться. Ровно черз 2-3 месяца до него дошло что статический конструктор вызываться всего 1 раз при обращении к классу. И вот скажите пожалуйста, как с такими бороться. Хотя если бы посмотрел в лог, то увидел бы всего 1 вызов: Код:
Console.WriteLine("Generate DB reader for type: " + type.Name); |