Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Ваші проєкти → Попереднє ознайомлення з hub.org.ua
Сторінки Попередня 1 … 5 6 7 8 Наступна
Для відправлення відповіді ви повинні увійти або зареєструватися
Воно нікуди не свистітиме - таблиця розтягується на розмір екрану, а мені треба навпаки - декілька таких таблиць поставити поряд, до того ж моноширинного шрифту нема, а без цього воно сунеться не так і не туди.
В моноширинному відображенні зірочки вже екранувати не потрібно, проте відступи все одно скорочуються до одного, що унеможливлює відображення вищенаведеної таблиці по-людськи.
Воно нікуди не свистітиме - таблиця розтягується на розмір екрану, а мені треба навпаки - декілька таких таблиць поставити поряд, до того ж моноширинного шрифту нема, а без цього воно сунеться не так і не туди.
В моноширинному відображенні зірочки вже екранувати не потрібно, проте відступи все одно скорочуються до одного, що унеможливлює відображення вищенаведеної таблиці по-людськи.
В такому разі роблять як треба локально і вставляють картинку.
Думаю легше і краще - додати підтримку codepen, або щось схоже
Підтримка codepen до речі існує.
Ось так можна вставити таймер з codepen, змайстрований нашим Анатолієм 
```
codepen:http://codepen.io/Anatolij/pen/bVxxEq/
```
Не перший десяток разів повертаюсь до проблеми категорізації для міток під публікаціями, кручу ними "і так, і так"... Здавалось би така проста задача, на перший погляд.
Найпростіший спосіб - надати можливість користувачам писати однорівневі мітки як їм захочеться, так як це зроблено на Stackoverflow.
Але в такий спосіб, по-перше, мітки можуть часто підбиратись абсолютно унікальні, котрі майже не будуть використовуватись іншими користувачами. Наприклад, якщо хтось вздумає придумати такі мітки як "відкриття однієї штуки", "у мене не виходить" і т.п. Очевидно, що вони будуть абсолютно марно займати місце в базі даних.
По-друге, такі мітки часто можуть бути досить неточними. Наприклад, однорівневі мітки "array", "веб-розробка" і т.д. мають неоднозначну й дуже широку область, тому вони теж будуть не ефективно описувати публікації.
На даний момент мені найбільше подобається ідея створення міток по формулі:
група, до якої входить певний бренд -> назва бренда -> певна мітка
Тут перші два рівня будуть статичними, користувач повинен буде придумувати мітку на місці фрази "певна мітка".
Ось деякі наприклади:
`Мови програмування -> JavaScript -> closures`
`Операційні системи -> Android -> emulator`
`Програмні бібліотеки -> jQuery -> visibility`
`Розмітка та стилі -> HTML -> checkbox`
`СУБД -> MySQL/MariaDB -> timestamp`
`Мови програмування -> SQL -> inner join` (знаю що SQL це не зовсім мова програмування, але це не велика погрішність)
`Веб-фреймворки -> Ruby on Rails -> authenticity-token`
`Фреймворки -> .NET -> enumeration`
Існує проблема з даною системою, бо такі доречні мітки можуть писати користувачі не нижче мідла в своїй області знань, мені так здається. Хоча, якщо написати чіткі правила для такого підбору, то може й джуніори придумуватимуть їх як належить.
Мій варіант правил на даний момент:
1. При створенні мітки, пам'ятайте, що вона повинна впізнаватись іншими користувачами, хто володіє знаннями з вибраного контексту для даної мітки.
2. Бажано щоб новостворена мітка була на стільки універсальною, щоб вона могла підходити до групи аналогів в своєму контексті. Наприклад, у прикладі
`Мови програмування -> JavaScript -> array`
та
`Мови програмування -> PHP -> array`
мітка `array` підходить до більше, ніж однієї мови програмування. В даному випадку краще вибирати саме мітку "array", навіть якщо ви хотіли б створити мітку "видалення елементу в масиві".
3. Можна створювати й більш унікальні мітки для вибраного контексту, але все одно вони повинні бути впізнаваними. Наприклад, `Мови програмування -> JavaScript -> use strict`.
Звичайно ж під формулу:
група, до якої входить певний бренд -> назва бренда -> певна мітка
далеко не усе підженеш, але спочатку спробую упорядкувати категорізацію для міток по частинам.
Що думаєте з цього приводу? Підійде такий варіант для широкого загалу, включаючи джуніорів?
На Хабрі взагалі хочуть мітки послати під три чорти. І ніби так краще, простіше. Але вони ніби й потрібні. Що гадаєте з цього приводу? Чи треба взагалі мітки?
Думаю, що це вони трохи не те роблять в цьому плані. Але їхній поворот в бік тіснішої інтеграції між "мой круг", гіктаймсом та хабром дуже доречна фіча...
Після оновлення в травні 2017 codeguida тримають досить помітний темп наповнення свого сайта. Контент є, редактори є, а де спільнота? Де жваві обговорення, де зацікавлення в такому ресурсі? Пів року пройшло...
Це я стосовно того, що дехто вважав контент самим головним чинником для розвитку, в даному випадку, мульти-блогінгу.
Ура! Найбільш рутинну частину на hub.org.ua - редактор постів та редактор для адміністрування категорій - завершено! Більше тисячі рядків коду лише для однієї сторінки. Хух.
А коли подивишся на той редактор, і не віриться скільки там логіки закладено.
Попереду ще трохи менш рутинна робота по підбірці категорій та підкатегорій для міток. А ще треба придумати як так зробити, щоб коли відсутня необхідна категорія та підкатегорія для міток, можна було безболісно додати її користувачу...
До речі, зараз на hub.org.ua крутиться стара версія сайта, нову додаватиму коли вже зроблю можливість голосувати (може через пару тижнів).
У себе нову версію стиснув ще трохи до 500 КБ. Тобто якщо порівнювати з ріплейсом, де сторінка важить біля 300 КБ, то виходить, що коли ви перейдете хоча б по двом сторінкам на ріплейсі, то ви вже завантажите більше даних, ніж важить SPA на Angular 5. А подальші переходи по SPA важать 3-10 КБ і мені це дуже подобається . Сайт справді виглядає помітно легшим навіть за ріплейсовський PunBB.
Як думаєте, дозволяти максимум 15 міток для однієї публікації - це багато? Щоправда, 15 штук не просто міток, а суми міток + їхніх синонімів чи близьких значень. Наприклад, для мітки dependecy-injection можна буде додати скорочення di у якості близького значення. В даному випадку під публікацією буде показуватись саме dependecy-injection, але публікацію також можна буде знайти й по di.
Підозрюю, що 15 шт. - це таки багато. Хоча хз, як думаєте?
Ладно-ладно, уговорили, зроблю 10 шт., думаю буде достатньо.
З якоїсь причини не проходить реєстрація. https://hub.org.ua/pre-account/set-password. На дії "ВСТАНОВІТЬ ПАРОЛЬ" після натиснення "Відправити" висне на процесі "обробка". Можливо, є обмеження на довжину пароля?
Ні, стара версія має відому проблему з виявлення змін. Вам достатньо клікнути в будь-якому місці екрану, щоб побачити справжній стан тієї зміни, яку ви робите.
Ви ж перед цим пошту підтверджували?
Мда, запит не виходить навіть з клієнта.
Я так розумію, що зайти на повноцінний сайт навіть в якості "гостя" можливо тільки після реєстрації?
Я так розумію, що зайти на повноцінний сайт навіть в якості "гостя" можливо тільки після реєстрації?
Так
