В конце сверстать пару страниц для закрепления и практики.
То есть практика будет только в конце, а все остальное время вы хотите тупо зубрить наизусть тэги и аттрибуты?
Это все - лишь инструменты.
От программиста (не путать с кодером) требуется вовсе не зубрежка инструментов (что само по себе звучит, как какой-то пиздец, типа: "я выучил перфоратор наизусть"), а понимание общей логики их работы, и различные навыки (в частности, навык динамически искать справочную информацию в интернете, а НЕ держать в голове), и все это приобретается исключительно на практике, и никак иначе.
Пока вы этого не понимаете, дальше и читать ваш план нечего, ибо вы такой ваш подход - полнейшее УГ.
Oleg Shevelev: > Кому не нужно? Вам? Вся суть проста, я пишу много софта под сервера, а сервера сплош на Linux.
Сисадмины - один из самых костных сортов ЦА.
Что нового вы можете для них разработать, чтобы они его еще и купили, хоть за 50 руб?
Вот я просто не могу себе такого представить. Под виндой возможности в сто раз шире.
> Надо понимать что GUI это не отдельное "нечто", это всего лишь дополнительный пакет к функциональности приложения.
Это одна из важнейших частей приложения.
> куда проще когда у вас 1 библиотека под подходящий по всем остальным критериям язык программирования
Кроссплатформенность библиотек - более разумно ТЕОРЕТИЧЕСКИ.
Но вы попробуйте ПРАКТИЧЕСКИ придумать библиотеку, которая подпадает сразу под 2 критерия:
1) она нужна хотя бы под виндой и под андроидом (остальные ОС мало-профитабельны вообще)
2) имеет смысл писать 1 кроссплатформенное ядро, а потом все равно писать враппер на C# (винда), враппер на Java (Android), враппер на Obj-C (Mac/iOS) - вместо того, чтобы просто написать отдельную версию на каждом из этих языков
Или вы считаете, что врапперы не нужны? Или считаете, что враппер - это просто: наимпортировал функций из ядра, побросал их кое-как кучей, и готов враппер, который "хорошо работает" и всем нравится, и от этой кучи Г*** не хочется блевать?
> Но ради Windows изучать С# не вижу никакого смысла. Никакого профита в других сферах это не принесёт.
1) Где вы видите сферы, под которыми вообще возможен профит, и которые не являются виндой?
Ну вот есть американские горки, у них мозги на базе ПЛК Siemens. Да, эта сфера не является виндой, и при этом профит в ней возможен.
Ну и какое же вы предлагаете написать кроссплатформенное приложение (или библиотеку), которое было бы нужно как на винде, так и на американских горках?
Никакое, это совсем разные сферы. А то, что похоже на винду, но ею не является (т.е. Linux и Mac), - по большому счету вообще мало-профитабельно, в силу особенностей ЦА.
2) "Никакого профита в других сферах это не принесёт." это даже отрицать противно.
Такое может сказать только рукожоп.
А для программиста, как я уже говорил, изучение чего-либо нового - ВСЕГДА полезно.
А C# - особенно, в нем куча уникальных решений, которые можно применить и под другими платформами. Взять хотя бы .NET, где его аналог под Android? Нет толком. А если взять и написать?
> пишите так как считаете нужным.
То есть пишите кривое, неудобное УГ, но зато кроссплатформенное.
Вроде OpenOffice, которому никогда не догнать не кроссплатформенный MS Office, и уж тем более не обогнать.
> но не в одиночной разработке
Как раз-таки нормальные инди вроде меня - это ниибаца какие спецы в куче направлений. Даже MS уже давно не торт, и им далеко до меня.
А вы - рукожоп.
> По большому счёту если вас всё так не устраивает в GUI библиотеках (закромя C# ... то что вы тут делаете?
Много что делаю.
В частности, даже такая отличная вещь, как .NET, все же далеко не совершенна, и нуждается в моих супернановысокоуровневых обертках, которые позволяют сделать разработку еще проще, удобнее, качественнее, быстрее... Этим и занят, пишу свои обертки для всего и вся. Делаю то же, что и DevExpress или Telerik, но делаю это не как они (они тоже рукожопы)) а как следует.
> У вас явно нет желания сидеть и делать нормальную GUI-библиотеку для Golang.
Рассматриваю и такой вариант, когда из серверного языка делают десктопный, создавая не только библиотеку для GUI! но и многие другие библиотеки, ну и IDE для всего этого.
Также рассматриваю вариант для C++ - написать нечто вроде своего Qt, только еще круче, мощнее и вообще в лучших традициях .NET.
А .NET в любом случае является эталоном для любого нормального архитектора, именно этот эталон нужно догнать и перегнать.
Но одно дело взять готовую пятиэтажку (т.е. .NET), надстроить ее супернанообертками и получить 7-этажное здание, а другое дело построить 7-этажку с нуля.
Высокоуровневые обертки для .NET я пилю прямо на работе в рамках рабочих проектов (возвращаясь к первоначальной теме вопроса - про архитектуру). А строить что-то принципиально свое с нуля- это отдельная работа, в сроки и бюджеты рабочих проектов ее никак не уложить, а отдельно мне за нее не платят.
Oleg Shevelev: > это ещё и GUI под Linux, Windows и любые другие операционные системы
Ну и НА***?
Сейчас очень модно гнаться за кроссплатформенностью, но на все тот же вопрос - НА*** - почему-то никто ответить толком не в состоянии. "Just for lulz" - вот к чему сводятся все попытки ответить.
Linux - коммерчески вообще не нужен, и точка.
Mac, Android, Windows - разные ОС, в большинстве случаев то, что нужно под 1 ОС, не нужно под 2 другими ОС.
> Вы пишете на всех сразу и одинаково хорошо?
Конечно. Пишу на туевой куче языков. И с каждым новым языком мои познания углубляются и расширяются, появляется понимание многих общих принципов, новые идеи для собственных продуктов в области Development Tools.
> Python
> - опять таки чем там рисовать окошки?
Ничем. Python - линуксячий ЯП. Линуксоиды любят консоль и скрипты.
А для виндузятников с их GUI идеален C#, и ничто иное до сих пор до него не дотянуло в этом плане, да и в других тоже. И вряд ли дотянет, ибо под виндой уже есть C#, а под другими ОС оно просто нафиг не надо. Это одна из причин, почему кроссплатформенность - не нужна.
> графические приложения что работают под Linux и Windows написанные на Golang не должны были бы так же хорошо работать под Mac OS.
Крупные приложения с GUI, написанные под винду не на C#, не работают особо хорошо.
Oleg Shevelev:
> у меня в планах так же софт с GUI под MacOS написанный на Golang...
Ну, может, хоть вы объясните, НАХ это все-таки надо-то? Есть же Obj-C, Swift, C++... Python есть, все ж таки не такой изврат...
> Пусть гуглит, изучает и распространяет знания.
Видел я на одном форуме одного подобного распространителя, который всех заипал таким вот распространением в холиварах. Все ржали с него.
Потом я сам попробовал то же самое, язык D так распространял, и та же реакция.
Если его цель в этом (чтобы ржали), то можно попробовать.
Для начала понимать бы, на кой оно надо.
Тут для имеющихся языков и то нифига не хватает норм библиотек, IDE, документации, а они свои сырые велосипеды строят...
Зачем динамическую-то?
Для WinAPI это как раз не очень надо. Он каг бэ не особо динамический с 1998-2000 гг.
А по динамическому импортированию, смотрим в сторону таких вещей, как разные dll explorer'ы, гуглим на тему "dll import functions dynamically", GetProcAddress и т.д.
Собственно, в винде уже есть средства для импортов функций из dll (т.е. GetProcAddress и т.д.), но можно и написать свой велосипед, который будет брать dll, открывать ее как бинарный файл, "парсить" нужную инфу и т.д.
А вообще, главная проблема вашего интерпретатора уж точно не в динамической загрузке функций, а как раз-таки в алгоритме разбора кода.
Если посмотреть на современные интерпретаторы, компиляторы, IDE, то по разбору кода это просто какие-то ИИ: как ни напиши, а все равно работает)))
Соответственно, писать такое - это адово сложная и тяжелая работа.
И увы, человек, который задает такие вопросы, может и напишет что-то "для прикола", но уж никак не юзабельный интерпретатор для продакшен.
Если вы нацелены на продакшен, то лучше посоветую писать что-то такое, что во-первых не требует столь сложных алгоритмов, а во-вторых не столь самобытно и в итоге людям будет легче к нему привыкнуть, чем к принципиально новому интерпретатору, где всё незнакомое и чужое.
Например, можно писать библиотеки. Гляньте на .NET. По большому счету, он мало изменился с 2003..2008 года, а ведь ему очень даже есть куда меняться и развиваться, я могу составить целый список того, что в нем не хватает или плохо. Так почему бы не написать к нему набор удобных, гибких, надежных библиотек/Extensionов, или еще круче, не переписать вообще всю библиотеку с нуля, от System.dll до GUI?
Для КАКОЙ БД?
Что за "microsoft database" вы выдумали?
Скажем, для *.mdb на любой не древней винде даже без .NET есть провайдер.
Для *.accdb уже нет, надо либо отдельно ставить, либо MS Access соотв версии.
Для SQL Server надо либо SQL Server, либо SQL Server LocalDB, либо SQL Server CE.
И т.д.
Виталий IIIFX Хоменко: хм, громкое такое заявление, учитывая, сколько я работаю, и над собой, и не только над собой.
КАК еще больше? Может, научите меня спать меньше 10 часов в сутки? Пытался сократить это время до 4, 6, да хоть 8 часов, но долго не получается так продержаться, какое-то время делаю больше чем обычно, зато потом крышу так заносит, что вообще ничего делать не могу.ф
> Если нет — когда его стоит ожидать?
Можно ничего не ожидать, а научиться работать с сайтами без API, через тот бек-енд, с которым работает штатная веб-морда. У некоторых сайтов вообще нет API, там только так и можно работать.
Сниффер Fiddler в помощь.
> А мне надо, например, на основе бд формировать меню.
> Наверное, есть какие-то классы для работы с бд
Есть. Данные не сразу попадают в грид. Их запихывают в DataTable или DataSet, а грид - это всего лишь телевизор, который привязан к DataTable или DataSet, показывает их содержимое и предоставляет возможность редактирования, и т.д.
Самое простое решение - это запихнуть данные в DataTable или DataSet, но грид не создавать, а работать напрямую с DataTable или DataSet. DataTable - это что-то вроде 2-мерного массива. DataSet - один или несколько DataTable'ов.
Возможно, это поможет: www.codeproject.com/Tips/1060352/Using-Microsoft-A...
там вроде был подобный пример.
Я сейчас отравился, туго соображаю, но по идее должно прокатить Task.Run + async-await.
await на то и await, чтобы будучи вызванным из async-метода ожидать, когда завершится Task, пущенный в отдельном потоке.
