Conform to Github Pages requirements for organization

This commit is contained in:
2017-07-06 21:54:19 +07:00
parent 90ba8c593d
commit e354274c7e
100 changed files with 282 additions and 801 deletions

View File

@@ -0,0 +1,50 @@
Title: Самоучитель iOS
Date: 2017-06-08 10:00
Category: News
Slug: ios-tutorial
Lang: ru
![Самоучитель iOS]({attach}/images/2017-06-08-ios-refactoring.png)
Эта статья описывает проблемы, с которыми мы столкнулись во время создания самоучителя для iOS в мае 2017.
[В феврале](https://twitter.com/OpenGameStudio/status/826816343433498627) мы сумели отобразить простую модель под iOS за считанные дни. Это дало нам уверенность, что самоучитель для iOS мы сделаем столь же быстро. Тем не менее, реальность напомнила нам о простой вещи: быстро сделать можно лишь поделку на коленке, работающую только у самого разработчика; над логически связанным примером, работающим у всех, придётся попотеть.
### Нативная библиотека
Прежде всего нам необходимо было ответить на следующий вопрос: "должен ли пример приложения быть частью проекта Xcode или отдельной библиотекой?"
Для принятия решения мы использовали следующие факты:
0. Проект Xcode может напрямую использовать C++ (благодаря Objective-C++) без прослоек вроде JNI
* Отдельная библиотека не нужна (+ приложение)
* Создание отдельной библиотеки - это дополнительная работа (- библиотека)
0. OpenSceneGraph собирается в библиотеки
* Легче использовать стандартный процесс сборки (+ библиотека)
* Создавать свой процесс сборки лишь для одной платформы сложно (- приложение)
0. OpenSceneGraph использует систему сборки CMake, которая не поддерживается Xcode
* Проект Xcode не может включать файлы CMake (- приложение)
* Свой файл CMake может с лёгкостью включить файл OpenSceneGraph CMake для сборки единой библиотеки (+ библиотека)
0. CMake может генерировать проект Xcode
* Можно создать файл CMake, который будет собирать как OpenSceneGraph, так и пример приложения (+ приложение)
* Xcode - это де-факто инструмент для создания проектов Xcode; легче использовать стандартный процесс сборки (+ библиотека)
Оценив плюсы и минусы обоих подходов, мы решили сделать библиотеку, которую можно включать в проект Xcode. Минусом данного подхода является то, что сборки приложения для симулятора и реального устройства используют разные сборки библиотеки.
### Рефакторинг
Также нам пришлось ответить на ещё один вопрос: "использовать ли единую кодовую базу для всех платформ или несколько под каждую платформу?"
При создании самоучителя для Android мы использовали единую кодовую базу, т.к. она отлично работала для десктопа и Android. Когда мы начали работу над самоучителем iOS, стало ясно, что часть функционала либо работает, либо не работает на некоторых платформах. Например, один функционал может работать на десктопе и iOS, но не работать на Android. Другой функционал может работать на iOS и Android, но не работать на десктопе. Т.к. мы не хотели загрязнять код кучей #ifdef, мы решили помещать функционал, специфичный для конкретной платформы или нескольких платформ, в разные файлы. Это привело к резкому увеличению количества файлов. Такой подход хорошо подходил для повторного использования, но совершенно не годился для понимания общей картины.
В этот момент мы осознали необходимость ответа на второй вопрос. Мы напомнили себе, что главная цель примера приложения состоит в том, чтобы обучить базовым вещам OpenSceneGraph, а не создать повторно используемую библиотеку с API, который будет жить без изменений десятилетиями.
Для ответа на этот вопрос нам помог наш внутренний инструмент feature tool. С его помощью мы разделили код на несколько частей, который в итоге собирается ровно в два файла для каждой платформы:
0. functions.h - содержит повторно используемые бесклассовые функции
0. main.h - содержит остальной код приложения
Их содержимое несколько отличается для каждой из платформ, но наличие всего двух файлов позволяет увидеть общую картину.
На этом мы заканчиваем описание проблем, с которыми мы столкнулись во время создания самоучителя для iOS в мае 2017.

View File

@@ -0,0 +1,50 @@
Title: iOS tutorial
Date: 2017-06-08 10:00
Category: News
Slug: ios-tutorial
Lang: en
![iOS tutorial]({attach}/images/2017-06-08-ios-refactoring.png)
This article describes problems we faced during the creation of iOS tutorial in May 2017.
[This February](https://twitter.com/OpenGameStudio/status/826816343433498627) we managed to get simple model rendered under iOS in just a few days. We expected to finish iOS tutorial in no time. However, the reality reminded us: it's easy to come up with a hackish demo that works for one person, but it's hard to create a concise example that works for everyone.
### Native library
The first question we had to answer was: should the sample application be part of Xcode project or be a separately built library?
We had to consider the following facts:
0. Xcode project can use C++ directly (thanks to Objective-C++) without stuff like JNI
* There's no need for a separate library (+ application)
* Creating a separate library is an additional work (- library)
0. OpenSceneGraph builds libraries
* It's easier to use standard build process (+ library)
* It's harder to create custom build process just for a single platform (- application)
0. OpenSceneGraph uses CMake build system, which is not supported by Xcode
* Xcode project can't include CMake files (- application)
* It's easy to create custom CMake file that includes OpenSceneGraph CMake file to build a single library (+ library)
0. CMake can generate Xcode project
* It's possible to create a CMake file that builds both OpenSceneGraph and the sample application (+ application)
* Xcode is the de-facto tool to create Xcode projects; it's easier to use standard build process (+ library)
After evaluating the pros and cons of each approach, we decided to turn the sample application into a library and include it in Xcode project. The downside of this approach is that simulator and real device builds need separate library builds.
### Refactoring
The second question we had to answer was: should there be a single source code base for all platforms or several ones, one for each platform?
While doing Android tutorial we used single source code base because it worked fine for desktop and Android. As we started to work through iOS tutorial, it became apparent that particular features may or may not work on some platforms. For example, one feature may work on desktop and iOS, but not Android. Another feature may work on iOS and Android, but not desktop. Since we didn't want to pollute the code with #ifdefs, we started to put each platform combination into a separate file. The number of files grew rapidly. The files were reusable, but it became extremely hard to see the whole picture.
At this point, we realized there's the second question. We reminded ourselves that the main purpose of the sample source code is to teach how to do basic OpenSceneGraph things, not create a reusable library with API that is stable across several years.
That's when our home grown feature tool came into play. With its help, we separated the code into several parts, which in the end produce just two files for each platform:
0. functions.h - contains reusable classless functions
0. main.h - contains the rest of the sample application code
Their contents differ slightly for each platform, but it's easy to see the whole picture now.
That's it for describing problems we faced during the creation of iOS tutorial in May 2017.

View File

@@ -0,0 +1,8 @@
Title: Моё первое ревью
Date: 2017-06-01 10:20
Category: Review
Slug: keyboard-review
Lang: ru
Вот и моё первое ревью, чуввви.

View File

@@ -0,0 +1,8 @@
Title: My first review
Date: 2017-06-01 10:20
Category: Review
Slug: keyboard-review
Lang: en
Here is a full review, guys.

View File

@@ -0,0 +1,10 @@
Title: kr1
Date: 2017-01-01 1:04
Category: Review
Slug: kr1
Lang: ru
kr1
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr1
Date: 2017-01-01 1:04
Category: Review
Slug: kr1
Lang: en
kr1
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr10
Date: 2017-01-01 10:04
Category: Review
Slug: kr10
Lang: ru
kr10
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr10
Date: 2017-01-01 10:04
Category: Review
Slug: kr10
Lang: en
kr10
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr2
Date: 2017-01-01 2:04
Category: Review
Slug: kr2
Lang: ru
kr2
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr2
Date: 2017-01-01 2:04
Category: Review
Slug: kr2
Lang: en
kr2
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr3
Date: 2017-01-01 3:04
Category: Review
Slug: kr3
Lang: ru
kr3
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr3
Date: 2017-01-01 3:04
Category: Review
Slug: kr3
Lang: en
kr3
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr4
Date: 2017-01-01 4:04
Category: Review
Slug: kr4
Lang: ru
kr4
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr4
Date: 2017-01-01 4:04
Category: Review
Slug: kr4
Lang: en
kr4
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr5
Date: 2017-01-01 5:04
Category: Review
Slug: kr5
Lang: ru
kr5
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr5
Date: 2017-01-01 5:04
Category: Review
Slug: kr5
Lang: en
kr5
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr6
Date: 2017-01-01 6:04
Category: Review
Slug: kr6
Lang: ru
kr6
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr6
Date: 2017-01-01 6:04
Category: Review
Slug: kr6
Lang: en
kr6
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr7
Date: 2017-01-01 7:04
Category: Review
Slug: kr7
Lang: ru
kr7
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr7
Date: 2017-01-01 7:04
Category: Review
Slug: kr7
Lang: en
kr7
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr8
Date: 2017-01-01 8:04
Category: Review
Slug: kr8
Lang: ru
kr8
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr8
Date: 2017-01-01 8:04
Category: Review
Slug: kr8
Lang: en
kr8
LANG: en

View File

@@ -0,0 +1,10 @@
Title: kr9
Date: 2017-01-01 9:04
Category: Review
Slug: kr9
Lang: ru
kr9
LANG: ru

View File

@@ -0,0 +1,10 @@
Title: kr9
Date: 2017-01-01 9:04
Category: Review
Slug: kr9
Lang: en
kr9
LANG: en

View File

@@ -0,0 +1,13 @@
Title: Обзор Pelican
Date: 2017-06-03 22:00
Category: Review
Slug: pelican-review
Lang: ru
Пока что полёт нормальный. Pelican действительно крут, позволяет
быстро всё настроить и запуститься.
Намного легче, чем Jekyll.
<3 Python и его экосистему. Что-то просто ЛЕГЧЕ в Python.

View File

@@ -0,0 +1,13 @@
Title: Pelican review
Date: 2017-06-03 22:00
Category: Review
Slug: pelican-review
Lang: en
So far so nice. Pelican is really cool, and provides a quick starting guided
to get up and running real fast.
Much more smooth than Jekyll.
I <3 Python and its ecosystem. Something is just EASIER in Python.

Binary file not shown.

After

Width:  |  Height:  |  Size: 395 KiB

View File

@@ -0,0 +1,8 @@
Title: О нас
Slug: about
Lang: ru
Мы команда Opensource Game Studio, студия игр с открытым исходным кодом.
Мы круты, ё.

View File

@@ -0,0 +1,8 @@
Title: About
Slug: about
Lang: en
We are Opensource Game Studio team.
And we rock, ya know.

View File

@@ -0,0 +1,13 @@
Title: Проекты
Slug: projects
Lang: ru
# OGS Mahjong
It is a super cool game
# OGS Editor
It is a super cool editor

View File

@@ -0,0 +1,13 @@
Title: Projects
Slug: projects
Lang: en
# OGS Mahjong
It is a super cool game
# OGS Editor
It is a super cool editor

60
pelican/pelicanconf.py Normal file
View File

@@ -0,0 +1,60 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*- #
from __future__ import unicode_literals
AUTHOR = u'Opensource Game Studio'
SITENAME = u'Opensource Game Studio'
SITEURL = 'http://localhost:8000'
PATH = 'content'
TIMEZONE = 'Asia/Novosibirsk'
DEFAULT_LANG = u'en'
# Feed generation is usually not desired when developing
FEED_ALL_ATOM = None
CATEGORY_FEED_ATOM = None
TRANSLATION_FEED_ATOM = None
AUTHOR_FEED_ATOM = None
AUTHOR_FEED_RSS = None
# Menu
MENUITEMS = (
('Projects', '/pages/projects.html'),
('About', '/pages/about.html'),
)
DISPLAY_PAGES_ON_MENU = False
# Blogroll
#LINKS = (
# ('OGS Mahjong', '/pages/ogs-mahjong.html'),
#)
PROJECTS = (
('OGS Mahjong', '/pages/ogs-mahjong.html'),
('OGS Editor', '/pages/ogs-editor.html'),
('OpenSceneGraph guide', '/pages/openscenegraph-guide.html'),
)
# Social widget
#SOCIAL = (('You can add links in your config file', '#'),
# ('Another social link', '#'),)
DEFAULT_PAGINATION = 10
# Uncomment following line if you want document-relative URLs when developing
#RELATIVE_URLS = True
ARTICLE_PATHS = ['articles']
# Custom TuxLite ZF based theme.
THEME="/home/kornerr/p/ogstudio-pelican-theme"
SHARE_BUTTONS = ['twitter']
#TAG_CLOUD = False
#PLUGIN_PATHS = ["/home/kornerr/p/plugins"]
#PLUGINS = ["tag_cloud"]
#tag_cloud = ['abc']

26
pelican/publishconf.py Normal file
View File

@@ -0,0 +1,26 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*- #
from __future__ import unicode_literals
# This file is only used if you use `make publish` or
# explicitly specify it as your config file.
import os
import sys
sys.path.append(os.curdir)
from pelicanconf import *
SITEURL = 'https://kornerr.github.io/pelican'
RELATIVE_URLS = False
FEED_ALL_ATOM = 'feeds/all.atom.xml'
CATEGORY_FEED_ATOM = 'feeds/%s.atom.xml'
DELETE_OUTPUT_DIRECTORY = True
# Following items are often useful when publishing
#DISQUS_SITENAME = ""
#GOOGLE_ANALYTICS = ""
OUTPUT_PATH = '..'