Программирование, т. 3

ну ты и в бэкбоне можешь подключить биндеры.

и без ивентов всё-равно ничего хорошего не выйдет

там есть ивенты, там даже есть абстракция под них

но можно писать без ивентов вещи которые на чистом жс написать нельзя (то есть эти ивенты скрыты от юзера)

 

да и не пойму нахуй ты так яро защищаешь бекбон, если это суть разные оперы

 

десу~~~~

 

Щас короче проект назревает, корпоративного масштаба. Ну я за главного, как бы это не звучало смешным для вас.

Так вот, это будет сложнее всего того, чо я делал в несколько раз.

Юзать фреймворк смысла не вижу, ибо нужна гибкость, да и само знание фреймворка.

 

Буду обдумывать архитектуру с нуля (ко-ко-ко велосипеды).

Есть время до понедельника, чтобы что-то прочитать, чтобы расширить свои представления о нормальном ПРОГРАММИРОВАНИИ

ну то есть, то что мне реально поможет придумать нормальную архитектуру, список интерфейсов, и т.д.

 

Есть идеи?

Кстати, может я имею не верное представление о слове архитектура.

 

десу~~~~

там есть ивенты, там даже есть абстракция под них

но можно писать без ивентов вещи которые на чистом жс написать нельзя (то есть эти ивенты скрыты от юзера)

 

да и не пойму нахуй ты так яро защищаешь бекбон, если это суть разные оперы

 

десу~~~~

 

Щас короче проект назревает, корпоративного масштаба. Ну я за главного, как бы это не звучало смешным для вас.

Так вот, это будет сложнее всего того, чо я делал в несколько раз.

Юзать фреймворк смысла не вижу, ибо нужна гибкость, да и само знание фреймворка.

 

Буду обдумывать архитектуру с нуля (ко-ко-ко велосипеды).

Есть время до понедельника, чтобы что-то прочитать, чтобы расширить свои представления о нормальном ПРОГРАММИРОВАНИИ

ну то есть, то что мне реально поможет придумать нормальную архитектуру, список интерфейсов, и т.д.

 

Есть идеи?

Кстати, может я имею не верное представление о слове архитектура.

 

десу~~~~

Конечно же есть идеи. Для начала нужно получить список требований. Разбить его по пунктам и группам. Потом написать спеку, после этого только можно приступать к дизайну. Параллельно с дизайном начинаешь думать о модулях и интерфейсах взаимодействия. Только так можно написать нормальное приложение, без лапши, богоклассов и нетестируемого говна для добавления в которое новой фичи означает полное переписывание всего кода.

Изменено 7 февраля 2013 пользователем DIMAN123456789

Я знаю все это, это собсно говоря все логично

Проблема вот какая - тз будет составляться в понедельник, и я уверен что оно будет дополняться по мере работы (но не критично дополняться). Точнее это не проблема.

 

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

 

 

Говоря совсем приближенно, я хочу сильнее погрузиться в ООП и, скажем, МВЦ, и в проблемы которые могут возникнуть при постоении архитектуры

 

и как блять писать эти ваши ебанные тесты, сука

 

десу~~~~

Изменено 7 февраля 2013 пользователем 2poy_nyasha

Я знаю все это, это собсно говоря все логично

Проблема вот какая - тз будет составляться в понедельник, и я уверен что оно будет дополняться по мере работы (но не критично дополняться). Точнее это не проблема.

 

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

 

 

Говоря совсем приближенно, я хочу сильнее погрузиться в ООП и, скажем, МВЦ, и в проблемы которые могут возникнуть при постоении архитектуры

 

и как блять писать эти ваши ебанные тесты, сука

 

десу~~~~

Тебе не нужно сразу начинать писать код и рисовать таблицы классов. Для начала пойми сколько у тебя будет слоев, какой за что отвечает. Ты же понимаешь что MVC это не панацея, возможно нужно будет писать L2 cache, делать хитрые секьюрити проверки, шаред контексты и прочее-прочее. Если об этом не подумать сразу, то потом все это вкрячить будет просто нереально. Но обо всем этом невозможно знать пока нет ТЗ. Замкнутый круг. Жди ТЗ, потом только видно будет.

у меня ТАБЛИЦЫ КЛАССОВ от вас

Я знаю все это, это собсно говоря все логично

Проблема вот какая - тз будет составляться в понедельник, и я уверен что оно будет дополняться по мере работы (но не критично дополняться). Точнее это не проблема.

 

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

 

 

Говоря совсем приближенно, я хочу сильнее погрузиться в ООП и, скажем, МВЦ, и в проблемы которые могут возникнуть при постоении архитектуры

 

и как блять писать эти ваши ебанные тесты, сука

 

десу~~~~

Тебе не нужно сразу начинать писать код и рисовать таблицы классов. Для начала пойми сколько у тебя будет слоев, какой за что отвечает. Ты же понимаешь что MVC это не панацея, возможно нужно будет писать L2 cache, делать хитрые секьюрити проверки, шаред контексты и прочее-прочее. Если об этом не подумать сразу, то потом все это вкрячить будет просто нереально. Но обо всем этом невозможно знать пока нет ТЗ. Замкнутый круг. Жди ТЗ, потом только видно будет.

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

 

Виза, хватит батхертить в каждом посте.

 

десу~~~~

Я знаю все это, это собсно говоря все логично

Проблема вот какая - тз будет составляться в понедельник, и я уверен что оно будет дополняться по мере работы (но не критично дополняться). Точнее это не проблема.

 

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

 

 

Говоря совсем приближенно, я хочу сильнее погрузиться в ООП и, скажем, МВЦ, и в проблемы которые могут возникнуть при постоении архитектуры

 

и как блять писать эти ваши ебанные тесты, сука

 

десу~~~~

Тебе не нужно сразу начинать писать код и рисовать таблицы классов. Для начала пойми сколько у тебя будет слоев, какой за что отвечает. Ты же понимаешь что MVC это не панацея, возможно нужно будет писать L2 cache, делать хитрые секьюрити проверки, шаред контексты и прочее-прочее. Если об этом не подумать сразу, то потом все это вкрячить будет просто нереально. Но обо всем этом невозможно знать пока нет ТЗ. Замкнутый круг. Жди ТЗ, потом только видно будет.

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

 

Виза, хватит батхертить в каждом посте.

 

десу~~~~

Я всем советую Макконнелла, Совершенный код. На мой взгляд, там наиболее полно и простым языком рассказано о всех этапах разработки и проектирования ПО, включая самые частые ошибки. Если не читал, советую. Причем её можно именно просто читать, там нет занудных задач, нет привязки к конкретному языку.

Изменено 8 февраля 2013 пользователем DIMAN123456789

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

и комменты сразу есть

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

и комменты сразу есть

все правильно

Если бы у вас свой язык был английский, то получившаяся программа бы была кодом на руби

 

А если тест - то спек для cucumber

Если бы у вас свой язык был английский, то получившаяся программа бы была кодом на руби

 

А если тест - то спек для cucumber

нeт

Если бы у вас свой язык был английский, то получившаяся программа бы была кодом на руби

 

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

Но не стоит же придумывать преимущества, которые ими не совсем являются. Тот же паскаль более "английский", чем руби. В свое время на нем дохуя чего написали. И глорили. И то же сейчас с руби (действительно считают языком поднимающим продуктивность). И вспомним где сейчас паскаль. И предположим где будет руби.

Тот же паскаль более "английский", чем руби

 

Что ты делаешь

 

АХАХАХ

 

прекрати

 

И предположим где будет руби.

 

А я и не говорю, что на руби будут писать еще 100 лет. Но руби (вместе с рельсами) уже произвели впечатление на всю веб-разработку, среди актуальных пхп фреймворков каждый что-то напиздил из рельсов. И если идеи пиздят - значит, они чего-то стоят.

Изменено 8 февраля 2013 пользователем Vizakenjack

Тот же паскаль более "английский", чем руби

 

Что ты делаешь

 

АХАХАХ

 

прекрати

 

Что-то не так с паскалем? ))

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

Если бы у вас свой язык был английский, то получившаяся программа бы была кодом на руби

 

А если тест - то спек для cucumber

hash = { :water => 'wet', :fire => 'hot' }

puts hash[:fire] # Prints: hot

 

hash.each_pair do |key, value| # Or: hash.each do |key, value|

puts "#{key} is #{value}"

end

 

# Prints: water is wet

# fire is hot

 

hash.delete :water # Deletes water: 'wet'

hash.delete_if {|key,value| value=='hot'} # Deletes :fire => 'hot'

 

заебись английский язык

Тот же паскаль более "английский", чем руби

 

Что ты делаешь

 

АХАХАХ

 

прекрати

 

И предположим где будет руби.

 

А я и не говорю, что на руби будут писать еще 100 лет. Но руби (вместе с рельсами) уже произвели впечатление на всю веб-разработку, среди актуальных пхп фреймворков каждый что-то напиздил из рельсов. И если идеи пиздят - значит, они чего-то стоят.

ничего это не значит, кроме того, что людям хоть бы что да спиздить нужно

ну руби - это паскаль для хипстеров

 

и в рельсах не было своих идей. была неплохая реализация чужих

Если бы у вас свой язык был английский, то получившаяся программа бы была кодом на руби

 

А если тест - то спек для cucumber

hash = { :water => 'wet', :fire => 'hot' }

puts hash[:fire] # Prints: hot

 

hash.each_pair do |key, value| # Or: hash.each do |key, value|

puts "#{key} is #{value}"

end

 

# Prints: water is wet

# fire is hot

 

hash.delete :water # Deletes water: 'wet'

hash.delete_if {|key,value| value=='hot'} # Deletes :fire => 'hot'

 

заебись английский язык

 

заебись жеж. А вот к примеру спек для тестов:

 

 

Feature: Post articles

In order to show trip photos
A owner
Should be abble to post article

Feature: Make comments

In order to contact
A user
Should be abble to make comments

Изменено 8 февраля 2013 пользователем Vizakenjack

короче, нужен совет по фасту. Позвонили насчёт вакансии php кодера, сказали блять что из всех кандидатов моё резюме понравилось больше всего и вообще у ихнего начальника привстал на меня(хз, наебали или нет, но нахуй им это). Зарплата от 80 до 120(что овер дохуя мне на данный момент)

 

Требования:

- хорошее знание php (от 3 лет), mysql, linux, apache, html, css, js; - ну тут всё по стандарту, правда с linux хуево разбираюсь

- желание и умение работать в команде;

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

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

- ответственность, исполнительность, обучаемость, стрессоустойчивость

 

Приветствуется:

- опыт работы в крупных, высоконагруженных проектах; - вообще нихуя в таких не работал

- опыт работы с nosql (mongo) - в душе не ебу что это такое

- опыт работы с Symfony; - опыт есть, но ничего серьезного не писал(юзаю Zend)

- знание и практический опыт применения шаблонов проектирования; - mvc знаю, с остальными не сильно знаком

- знание API социальных сетей; - толком нихуя не знаю

 

Короче, стоит ли мне рыпаться и реально ли заполнить пробелы в знаниях прям по ходу(готов ебашить 24/7)