I have just finished development of a web service/UI with Hugo as the static site generator and git with GitHub for version control. I done it as an experiment to learn Javascript both for the client and server side.
Most of the bugs is found and fixed. Now the big question is how it works under heavy load, cpu, file handlers etc. It became more difficult to develop than what I possible could have imagine. Everything on the server side is non-blocking, asynchronous and works in parallel.
My next step is to write instructions, build some new themes, blog about the development, how to use it etc⌠Check it out at: Appernetic.io
I donât think youâll get much feedback around here. I built something similar and posted for feedback but didnât get any. Iâll try out your app and let you know. The UI looks pretty, so good job on that. Also are you running the hugo generator on the same server as the site is hosted?
Hi,
thanks for your feedback. I only use the server for static Hugo site generation and then let the user push it to GitHub after previewing the site, because of caching. Iâll will check out your service!
Great job on the speed of the site, It is very fast. A few things which can be improved:
Navigation is confusing, themes/images are under the publish button and I didnât find a way to upload images (I tried doing it from the markdown editor and was able to )
The codemirror editor and the markdown editor are very nice. Good job on that.
My suggestion to you would be to get a new user and ask him to use your website and take notes on what stuff is confusing. The navigation definitely needs work. Other than that it looks like a really well made app. I wasnât able to test out the deployed site because of an error in a theme though.
Thanks to Node.js and Redis it is fast. I also use Cloudflare as a CDN.
My idea was to have the dashboard clean and uncluttered with as little buttons as possible, therefore I put them in one drop down button group with the most used function âPreviewâ in the first place. The drop down is a problem in a mobile browser because the touch field is very little other then that it works, I think. Time will tell and what the majority of users think. For now I keep it this way.
The editor was very difficult to make it behave nice with upload and Angular in particular. I have evaluated, tested and digged deep in the code of many markdown editors and every time got back to PageDown. Itâs not the best, fastest or most nice looking editor but it works quiet well. I am missing headline buttons and need to work on better list functions and also add shortcode functionality perhaps.
In the coming week I will have new users testing the site.
Yes it is annoying with error in many of the themes. Even though it is error messages, most of them still work when you deploy them such as hugo-icarus-theme.
Thanks for your input!
Lots of work now with instructions, faq, disclamers, pentesting, backup, maintenance, layout, support and blog articlesâŚ
This might be just a me thing⌠but I think itâs worth saying. Had I not seen you here (as part of the community), I definitely would be a lot more put off by this:
Log in with your GitHub, Twitter or Facebook account. Creating a Github account is like signing up for Facebook or Twitter. Youâll give your name, username, email address, and set a password.
I get that, for the service to work, the github connection is needed. But to see a demo I have to give access to my Github, Twitter or Facebook account would make me uneasy.
For what itâs worth, I think enabling the demo access before log in would be better. I would just require log in / sign up where there is a need, or just have your own sign up system that is not requiring the user to give potential access to their personal services / data.
I was going to try the service. But I am one of those people who wonât give access to my data where it is not clearly required.
Hi,
yes, you have a point there and the full right to be worried about giving access to your data.
First, the service only get access to:
basic profile (users public profile)
email address
public repo (read/write)
Nothing else, no password, no private info. You will see this when you login and you also have to confirm it when you give Appernetic access to your GitHub account. Maybe it is too much for the demo.
When I developed the service I did not consider having a demo, so as an afterthought the easiest thing was to keep the login but use my GitHub account in the back-end. It also feels safer for me to know who is using the system and I do not have to check the published site all the time for content that is not following GitHubs guidelines, which will be a big problem with no login or unverified accounts. This way I have only serious users.
I also thought that it was more convenient for the user who doesnât have to register or sign in again if he decides to subscribe.
If I use my own sign-up system I have to maintain a database, send out email confirmation and have a way for users to reset passwords.
So my solution was the best I could think of, faster to develop, safer for me and the service and GitHub, convenient for the user and the user is not giving up sensitive information.
I will have to think of a good solution for this, but I think it will be difficult.
Sure, and not saying I have a great solution to this (as not wanting the DB, etc is understandable given where we are). My suggestion would be to have the demo available without sign-in, and lose the Facebook / Twitter options (as I think there are enough that might be put-off by priivacy concerns because they are there). But just a subjective opinion which may not be how most others see it.
Ha, I wouldnât describe it as that. Maybe just some left over jealousy from having really struggled to get php to work nicely with github when trying to create a way to transfer files automatically.
Sounds good though. I fully intended to test the service but havenât got around to it yet.
I couldnât stop thinking about the problem, so I had to try to solve it. So yes it was a positive kick in the ass!
It was an enormous struggle to get node.js to work with github and git, but it is a good way to learn javascript and keep away from PHP and Coldfusion.
No I donât like PHP. I donât like the syntax and I like it less now because of its flaw/density ratio as the most riskiest programming language after Coldfusion and classic ASP.
With node.js and angular.js you can build anything and there is a large community.
Though I think PHPâs security flaws are more to do with the overuse of poorly made cms systems (built like Lego with loads of modules), and lack of regular updating.
Angular.js looks great, but seems quite a departure from standard javascript, therefore widening the gap client / server-side language (which seems to be a reason Node gets recommended).
(Iâm not really qualified to argue on this one as I only know node.js as a desktop tool and am not up to date with the newer tools of either technology)
EDIT: by âpoorly made cms systemsâ i mean the way they are used and offered to clients, not the job done by the cms development team.
We just shipped a new freemium version of our static website generator: https://appernetic.io
The only thing that is crippled is how many times you can publish each week, which is seven at the moment.
