Доброго времени суток!
В дизайне я 0, ну не умею рисовать и все... Стоит ли мне изучать php как и другие языки/технологии для веб программирования, стану ли я полноценным веб-девелопером ?

Конечно, стоит попробовать. Только начните с HTML.

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

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

djman2006, главное чтобы ты САМ хотел этим заниматься.

Ок, спасибо за советы, наверно все-таки попробую.

M skyboy

переместил из раздела РНР

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

Согласен со всеми вышеотписавшимися, дизайнеры, как правило люди творческие, можно сказать - гуманитарии, а программист должен быть в первую очередь отличным математиком, чтобы составлять алгоритмы и иметь очень развитую систему сотсавления именно математических моделей, и там, и там нуно иметь хорошее абстрактное мышление, но дизайнеру главное сделать красиво, а тебе сделать фуункицонально, что есть то же самое Красиво, но на языке программирования.

Круто, когда в человеке это сочетается и оба направления ему нравятся, но это редкость. В крупных компаниях есть разделение труда) ...

Простите, а каким боком дизайн относится к PHP? Это вещи абсолютно не связанные.
Дизайны делает дизайнер, а на PHP пишет программист. Если уж на то пошло, то верстает верстальщик(обычно сочетается с дизайнером, иногда с PHP-программистом)

А лучше уметь то и то...что-бы  работать в одиночку.
Риссовать научиться не трудно..в сети массы уроков по фотожопу и др.
Главное никуда не торопиться.и всё будет.  

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

Мне всегда было интересно, откуда берутся эти красивые картинки на сайтах? Оказывается дизайнеры нафотошопили.       
(всегда думал что веб-программист должен уметь всё)

Это называется эникейщик.


Тогда почему кругом столько непрофессионального, убогого дизайна?

QryStaL, 

Потому что рисовать научиться нетрудно 

Трудно научиться делать это хорошо.

Вот именно. Совмещающий все-в-одном специалист с 99% вероятностью ничего качественно не сделает...

Это называется IT псециалист в России, иногда величают сисадмином...


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


1. Все зависит от специалиста. Пример - Туполев, Королев и многие другие конструктора, которые не только умели фюзеляж собрать, но знали толк и в электронике и навигационных системах...
2. Все зависит от заказчика, как он будет со спецом работать.

Это исключения, входящие в вышеназванный мной 1%. =)

не, в России это называеться швейцарским ножом - должен уметь ВСЕ, а что не умеешь делать - то учись...

HTML + PHP +JS + AJAX+ ДИЗАЙНЕР 
я тоже рисовать не умею 
пишу вполне сностно все довольны кроме дизайнера 
который неоч любит код сводить с дизайном

Просто веб-дизайнер, и просто веб-программист -- несовместимы, ибо это веб!   

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

чаще всего встречаются Верстальщики + PHP программисты, я бы сказал в большинстве случаев... т.к. когда кодят и верстают разные люди уходит больше времени на разработку, в итоге достаточно знать HTML + CSS + PHP + JavaScript (ну и все что входит в web-программинг)...

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

Если сейчас на перепутье - выбирай что угодно: руби-на-рельсах, питон, коммонлисп+анкоммонвеб, да хоть ту же яву. Только не похапе. Это полумертвая технология. Да, сам я профи по части похапе, но я все больше в этом убеждаюсь.

прям технология и прям мертвая? 
похоливарить охото?   

Я разбираюсь в HTML, CSS, JavaScript, тока опыта немного, вот хотел заняться ПХП, а тут такая фраза)))

С этого места поподробнее, пожалуйста)), какие доводы, что ПХП мёртв? Или это просто, извините, "выпендрёж"?

Я позволю ответить за Мутогена.
Веб в текущем состоянии достиг своего программного максимума. ПХП выжил ВСЕ из того что можно делать для веба. Дальнеейшим (но не последним) развитием веба будут ГУИ приложения на Java, ActiveX. PHP тут уже по большому счет будет не особо нужен, а на этот уровень он не перейдет. Грубо говоря уже не технологично клепать сайтики каким-то там html'ом.

Ну и второе, тут уже, имхо, ПХП с точки зрения технологии программирования - дырка. Язык очень гибкий, но эта гибкость, к соэалению в 99% случаев оборачивается совершенно бездарным кодом...

 Ой ли? )
Java в виде апплетов мертва давно и... глубоко.
Про ActiveX думаю и заикаться не стоит.

Скорее всего ты имел ввиду Flash(Flex/AIR) и Silverlight(правда не в ближайший год точно).

А во вторых ты забываешь про backend для таких приложений - тут PHP очень даже ничего.

И еще: не всем нужны такие сайты. Грубо говоря "не всем" = "большинству". Поэтому PHP загнется ой как не скоро.

 Это просто следствие из того, что уровень входа в него низок.
Просто не смотри на код новичков. 
А код прошаренных программистов на PHP и, допустим, джаве очень близок по качеству.

С Mal Hack полностью согласен, но хочу сказать и пару слов от себя. Задумайсь о том, засчет чего вообще жива 
эта технология.

за счёт 20 000 000 сайтов написанных на нём?

Вы сильно заблуждаетесь вместе с MuToGeN  впрочем посмотрим ;)

У меня сейчас 2 заказа на промышленные приложения на PHP, из последнего над чем сейчас работаю это soap, distributed transactions etc. И надо сказать, что PHP интенсивно мигрирует в этом направлении.

Ну я в данном случае имел ввиду архитектуру работы, т.е. приложение - как JA или ActiveX или флеш. Я с ними не работал поэтому в каком они состоянии находятся плохо представляю. Но вы меня поняли.


Для бэкэнда ПХП уж слишком раздут... =) Хорош, не спорю, но раздут. 


Это какие? 
Загнется-то понятно не скоро, я про то, что куда тенденция пойдет крупных порталов, а частные странички аля я Вася Пупкин - да, будут делаться на ПХП, но, сам язык будет стоять на месте, ибо развиваться негде.


На то они и прошаренные. А вот вся 14-17 летняя милюзга, которая кое как написала 20 строчек кода и  считают себя мега программистами PHP? PHP дает возможностей много, а вот отличить профессионала очень тяжело...


Perl, который в свое время достиг максимум своего развития, между прочим - яркий пример. В область выше уровнем, он не вылез. Так и остался для своих shell-script целей... А писали на нем ой как много...
Это естественная эволюция.


Что вы называете промышленными приложениями? Что за контора их заказала? Что система должна делать?


Уровень выше - ГУЙ, а в ПХП это НИКАК не предусмотренно, а следовательно развивать некуда.

И



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

Я думаю что по своему смыслу как таковому, HTML, CSS, JavaScript, PHP, не только умрут не скоро, но и вообще фиг знает когда умрут, согласен, развитие рано или поздно прекращается, но использование этих технологий нисколько не сокращается...



Это сообщение отредактировал(а) ДобренькийПапаша - 22.7.2008, 16:30

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

Т.е. генерирующую и обрабатывающую от 100 до 10000 документов в день с сопутствующими им транзакциями. С соответствующими требованиями к надежности и устойчивости. Распределенную по времени и пространству. С возможностями интеграции с различными другими системами. С возможностью подключения произвольного набора переферийных устройств и т.д. и т.п. 


Какое-то однобокое представление о уровнях. PHP-GTK впрочем отвечает и на это странное предположение.
Я бы делил уровни по сложности и используемым технологиям... а не GUI vs Console.

Хотите вы того или нет, но сейчас очень много решений переносятся в веб. И в данном конкретном случае GUI предоставляют браузеры.
А это значит, что любое приложение пишется на нескольких языках. Как справедливо заметил nerezus на backend-роль отлично подходит PHP. На чем реализовывать frontend - это уже дело вкуса. Мне пока достаточно HTML+JavaScript.

Займут свои небольшую нишу, как Перл, например. А на ведущие позиции выйдут другие.


Вы меня извините, но работу крупной компании обеспечивают такие системы, как 1С, Axapta, Navision, SAP.
И вообще термина "промышленное программирование" не существует.
http://ru.wikipedia.org/wiki/Сравнение_язы...рограммирования


Транзакции к документам отношения не имеют, это раз. Два, даже 10000 - фигня...


Это общее требование.


Это как? Что такое распеределенное программирование я знаю. PHP на это не способен в принципе.
И эти задачи решают исключительно на других языках.


Это с какими простите? Мыши, Клавы принтеры, сканеры отменяются по любому, если брать девайсы, так сказать, не относящиеся к ПК, то как вы с ними работать собираетесь? Они все сидят на интерфейсах, с которыми ПХП работать в принципе не сможет. Ни RS-232, ни 422, ни 485, ни многие другие, а уровень поддержки TCP скорее всего будет недостаточен.


В данном случае для PHP это следующий вид эволюции. Тут "уровень" имелось ввиду концепций, гуй - консоль.


Если бы отвечало, на нем бы программы писали, а так, испоьзуют (т.к. я все-таки по большей части с С++ работал то и примеры к нему относящиеся) MFC, ATL, QT, boost и другие.
http://ru.wikipedia.org/wiki/Событийно-ори...рограммирование - в ПХП никакой событийности - нет.


Я с вами в данном контексте не соглашусь со словом "веб". Сегодгня тенденция - по созданию сетевых приложений, и веб тут не при чем, использование глобальной сети еще не означает использование концепции WWW. От этого между прочим, серьезные фирмы стараются отходить. В качестве примера. Сеть магазинов электроники,в залах, обращается к  БД, не оимеюший отношения к вебу, а вот в книжных магазинах - наоборот. Другой вопрос, что есть некая интеграция, когда PHP скрипт получает доступ к обновлениям основной БД, но с  ней не работает по полной программе.

Кхм,кхм. 
так и вертится вопрос про опыт в написании калькулятора - но не задам... "Как страшно далеки они от народа..."

Мне жаль, что приходится прописные истины объяснять тебе. Но слишком уж вызывающий тон у тебя при полной некомпетентности. 
Здесь Документ - это не веб-страничка. Это та правовая основа, которая разрешает и регулирует любой действие в крупных компаниях. 

Понятие транзакция относится не только к действиям в базе, но и вообще к любым завершенным действиям. И бизнес транзакция может включать в себя десяток транзакций в базе.

В бизнесе (в крупном) источник любых телодвижений с базой это документ/операция. Например Sales Order/продажа, Loan Order/заем/аренда etc. Каждый из этих документов/операций может порождать пачку производных от него равно как и транзакции в базе.

К примеру в Приватбанке ежедневный документооборот по платежным поручениям, в то время когда я там работал, был свыше 1млн штук в день. А в отдельных филиалах от 10т-100т.
А число транзакций в базе могло достигать полумиллиона только в одном небольшом филиале.


Не путаем distributed transaction и распределенное программирование. Это разные вещи...
Впрочем, ознакомся хотя бы с этим http://ru.wikipedia.org/wiki/%D0%A2%D1%80%...%86%D0%B8%D1%8F
и вот этим
http://en.wikipedia.org/wiki/Distributed_transaction



Различные barcode-scanners, принтеры, весы, кассовые аппараты и т.д. 
PHP поддерживает ПК - этого более чем достаточно. Все что не поддерживает TCP, легко оборачивается небольшими трансляторами написанными на чистом C.


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

И вообще...
Поощряется использование MVC даже в декстоп приложениях, не говоря уже о PHP. Да я понимаю, что это зависит от уровня программиста.
Но поскольку сам я не совсем программист и тем не менее мне данная архитектура более чем удобна и прозрачна, то мне тем более удивительно слышать такое из уст специалиста.


Веб - позволяет это сделать с минимальным уровнем вхождения  И надо сказать что сейчас в мире доминирует принцип KISS, DRY и backward compatibility. Та же MS вышла в лидеры во многом благодаря сочетанию этих вещей.

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

Так что достаточно лишь немного подождать и увидеть во что это все эволюционирует 

Добавлено через 2 минуты и 52 секунды

Опять не понимание.... Enterprise level application - такое существует?

Относительно тона я тоже самое могу сказать и по вашей фразе, что мы с мутогеном сильно ошибаемся ;)


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


При наличии грамотно разнесенных для работы серверов пол миллиона транзакций для БД - не проблема. На сегодняшний день, конечно же.


Я несколько не правильно понял содержание вашего предыдущего поста.


1. поддержка ПК - далеко еще не все. Вы мне скажите, как в с COM портом в ПХП работать будете?
2. простая "обертка" тут не поможет, поскольску вам надо ей управлять, для винды это критично.



Для создания ГУИ приложений.


А где она есть? Покажите. __call и прочие - это не событийность...


Представим такую ситууация. Вам надо пойти купить минералки в магазин (отправить пакет, получить пакет - данных имеется ввиду). Зачем вам надо заходить в другой магазин, чтобы купить полиэтиленовый пакет, если он вам будет дан уже в том же магазине? Зачем делать лишние телодвижения?
В принципе я описал такие системы выше...


Можно, не спорю, но именно веб-приложения, где нужно чтоб юзер обращался к информации по средствам HTTP, HTTPS протоколов.


И что? Сколько из этих сайтов сделано профессионально? Наиболее крупные корпорации, между прочим, ПХП не используют. По крайней мере 2 года назад, точно могу сказать, что ни Яндекс, ни Мэил на нем не работали (вроде как и рамблер).


Вопрос во что... В гуй? Нет... Этого не будет. Это 70% транслятора нынешнего надо писать...


По-моему, и как это озвучивали на Microsoft Bussines solutions называется это системы управления предприятием. О некоторых системах я говорил выше. Писать это на ПХП - самоубийство. По крайней мере на уровне NAvision & Axapta. Более простое еще может быть.

Никак.
Нет, это можно сделать на PHP - но глупо.

для этих целей лучше использовать специальные "драйвера" обертки. Впрочем, если речь идет о реалтайм приложениях - то тут PHP просто не подойдет.


Это было 4 года назад. Впрочем, если сильно не вдаваться в подробности, там была система БД в филиалах с репликацией на основной сервер. И то и другое на Sybase, только разных версий.
Так что про объем транзакций в головном офисе я могу только гадать 



Model - база данных
View - html, javascript etc...
Controller - PHP.

со стороны клиента имеем обычый браузер для GUI. 
Вот пример, который я люблю показывать. http://extjs.com/deploy/dev/examples/desktop/desktop.html


С помощью их можно реализовать 90% типичных задач предприятий.


Представления не имею. Но полагаю счет идет на 10тки тысяч 


Да дался этот, прости господи, гуй... Это не вершина сложности в программировании 
Более того выше я уже давал схему.


С 5-7 недопрограммистами моего уровня - я бы взялся  где-то около года работы.

Добавлено через 3 минуты и 22 секунды

И да, для сотен документов в день я писал фактически в одиночку. Особенно мне понравилось работать с legacy DB. Я был просто в восторге от денормализованных таблиц на 100-150 полей.

Предыдущая попытка (до меня) делалась на java - они не прошли по производительности 
В текущем состоянии пока держимся 

оффтоп:ну вы тут нагородили...вы тему-то посмотрите, если всё так серьёзно, интересно было бы подискутировать в отдельной теме по поводу будущего вышеуказанных технологий, в частности пхп))))

Вот я как раз и про это. Управлять через COM порт на Винде вы не сможете 100%, вы просто визически не сможете закинуть в винду Device Control Block необходимый, для того, чтобы ОС разрешила работать с портом, как надо.


А как правило-то, работать тадо именно так.


Так клепать view на html - весьма затруднительно, по сравнению с визуальными средствами Delphi, MFC, Qt, etc...
А они уже содержат средства для организации контроллера.


По сути - обертка обертки... Не технологично.


что составляет 0.00N % =) Лично мое мнение, что счет идет на пару десятков тысяч даже...


Я к тому, что зачем использовать веб как промежуточный пункт, когда можно сразу наладить взаимодействие по TCP/IP. Когда задача еще в веб-интерфейсе (инет магазины), то тут да, другой вопрос.


Вы видели Navsion & Axapta в работе? Лично я видел только официальную демонстрация MS.Если не пить не есть, за год функционал написать может быть и можно, но при этомзабываем про отладку ;)


Я наверное несколько не так выразился в следствии чего моя мысль до вас не доходит как этого хотел бы я.
В данном контексте я имел ввиду развитие языка с точки зрения предоставления возможностей программисту. Для ПХП следующий этап - ГУЙ. Я согласен с вами, что ГУЙ это не верх сложности, да и сложность определяется задачей, а не технологиями или типом приложения, но куда ему развиваться дальше? Он и так превращается в большой фрэймворк %)

ДобренькийПапаша это модераторы при желании пусть тему расщипляют =)

Зато можно сделать абсолютно платформонезависимо  в отличии от...


Встречный вопрос, а меня видели в работе? 


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

Добавлено через 2 минуты и 41 секунду

пресловутая кроссплатформенность.

Моя последняя задача идет и на Linux и на Win2003 одинаково хорошо 

Ну почему... Да, Delphi, MFC - в этом плане тугие. А вот Qt- очень даже...
К тому же решается проблема стандартизации HTML кода, т.к. всем браузерам на эти стандарты по большому...


Нет, не видел, но не хочу вас обидеть ни в коем случае, но это нереально физически сделать за год систему аля Navision. полностью ее отладит... ИМХО, конечно.


Вот... Так вопрос-то изначально был в том, что эта ниша, имхо, будет подвинута, причем очень сильно ;)

И не пойдет он по пути ГУЯ... ну не будут разработчики 70% транслятора писать снова =)

А вот это очень интересный вопрос  кстати
Что проще, сделать кроссплатформенный html (на внешний вид плевать, пока говорим о функциональности)
или код на C/C++? 


Люблю невыполнимые задачи  Они интересны и за них очень хорошо платят.

Я бы поспорил, но 5х меня у меня нет 


Веб? Нонсенс 

С точки зрения времени однозначно кроссплатформенный гуй на С++ сделать легче, чем на html.
С точки зрения технологии... Ну тут зависит от программиста. Кое как наклепать html - дело не хитрое. Сделать качественно, подогнав под все браузеры - вопрос хороший.. В Сях это придется просто сделать...


Согласен, но есть реалии =)


gopher же подвинулся =)

Посмотрим 

Добавлено через 1 минуту и 4 секунды

Можно при желании провести эксперимент. Какой объем функциональности желателен? 

 В этом и дело. Ну не смотри на мелюзгу!
Если ты не можешь их отсеять, то это твои проблемы, а не проблемы языка. Смотри только на профи!

 Сначала бы разобрались с проблемами в thread safety в PHP...  Кстати с ней решилась бы и проблема с многопоточностью.

Можно, но не в этой жизни, ибо работы до фига =)
Вот сколько помню, время, которое мной тратилось на формирование цивильного  html кода много больше, чем я делал GUI, будь то на BCB, Delphi, Qt... =)


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


К сожалению, это проблемая языка в том числе. Язык падает в глазах многих людей, когда они видят кто на нем пишет. В свое время, как только появился ПХП 4, пхп программисты были одни из самых уважаемых спецов, а сйечас? Как обычный верстальщик какой-то...

А сейчас нужно доказывать, что ты того стоишь 
Ну и что? 

Добавлено через 58 секунд

Сапоги должен тачать сапожник, а печь пироги пирожник 

Верстку отдай спецам они это сделают в разы быстрее и правильнее 

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


Да тоже понятное дело, но тем не менее.. В свое время я и html писал адекватно =)
При проектировании системы ГУЙ, какая бы у него реализация не была, все равно надо учитывать..

Не только. Еще за счет того, что оно интуитивно понятно любому. Тут есть и обратная сторона медали - для того, чтоб считать себя именно программистом, знать определенную технологию мало, еще как минимум нужно быть последовательным в своих суждениях. И как раз из-за того, что тут все так просто, и появляются все эти умники, называющие себя программистами, но на самом деле ими не являющиеся.

Добавлено через 7 минут и 38 секунд
Да, продолжаю свою мысль: в результате из 10 человек, считающих себя программистами, только 1 хоть в чем-то похож на программиста. Работодатель из-за этого сталкивается с проблемами при подборе кадров и рано или поздно скажет: "все, мне это надоело, лучше найти банду аспнетчиков или питонистов и все переписать". Вот примерно так как-то.

Бывший начальник любил очень простой вопрос - как именно работает механизм сессий? Я ради эксперимента когда-то спросил пару знакомых по аське, в результате начитался такого откровенного бреда, что поднял себе настроение на неделю вперед.

Мне по админским делам PHP на CLI SAPI кстати очень часто пригождался, даже несколько собственных библиотек накатал.
А насчет GUI... Когда-то, помнится, сами ребята из Zend хотели делать гуевый фреймворк. Только то ли в процессе поняли, что не судьба, то ли всеж доделали, но об этом ничего не слышно.

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

и среди них не найдётся той шушеры, что напишет ту же лажу?

Мне скоро на работу устраиваться, вот сижу создал файл "Что нужно знать"))))
и записываю в блокноте всё чего вы тут понаписали)))))))

Вообще собсна полазил по форуму (эта тема, тема "опыт устройства на работу"), почитал что нужно знать, позаписал, буду учить)))
Как думаете, правильный подход?)))))

Это сообщение отредактировал(а) ДобренькийПапаша - 23.7.2008, 10:31

Вероятность есть. Но эта вероятность гораздо ниже.

Тут скорее дело в том, как оно изучалось. Если "сверху вниз" (т.е. начиная с высокоуровневых технологий), то человек навряд ли что-то поймет. Другой вариант - человек сначала понимает, как все происходит на уровне ассемблера, потом постепенно переходит на более высокоуровневык штуки.

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

 А зачем на работу таких принимать?
Вот приняли - значит и виноваты.

GUI для web это не GUI для программ ОС, поэтому то что есть фреймворки, и то что GUI не хватает PHP, да это все эти GUI только усложняют жизнь верстальщикам и программистам при верстке даже средней сложности дизайна... 

Но я бы не советовал входить в программирование в PHP, уж лучше начать изучать с Python'a или с Паскаля... изучить другой язык в дальнейшем будет как пару пустяков.

Знаешь, программирование оно вообще усложняет жизнь программистам 

Кстати...
В ПХП есть междумордие к GTK, я где-то месяц назад что-то типа сапера накатал. От нечего делать. Это на тему ГУИ.