formula1 / NodeOS-Blog

Blog for NodeOS based off github issues
7 stars 3 forks source link

Own page for posts #2

Closed piranna closed 9 years ago

piranna commented 9 years ago

AFAIK Angular support History API to create paths although being a single-page framework, so it could be used to show pages for each one of the post and probably have a better SEO. The simple path would be to use the issue ID but its ugly, a better way would be to use the issue title but this would require some mapping doing a request to the server to get all the post and later show the correct one, wasting bandwidth.

formula1 commented 9 years ago

I'll get started on that tomarrow, makes sense for the most part

Check current url to find out where we are
-If an issue-Render Issue View
-If index-Render index view
-If anything else-Render 404
Issue click -> History API -> Render View

Render View
-Get the specified issue-If not there, 404
--Display in rendered View
piranna commented 9 years ago

Great :+1: Issue view only show the issue and the comments (two requests... Reuse issue content when comming from Index view?), we'll left to publish comments as a future task ;-)

piranna commented 9 years ago

http://oauth-io.github.io/oauth-js/

Hum? If it's true, then we could have fixed this... :-D

piranna commented 9 years ago

Hello.js seems to offer the same functionality :-) Good to know there are OAuth libraries for pure server-less apps! :-D

formula1 commented 9 years ago

Jeeze man, your google-fu is impecable. Granted I wasn't thinking about it today but these are some good finds!

piranna commented 9 years ago

github oauth serverless did the trick ;-)

piranna commented 9 years ago

https://developer.github.com/v3/issues/#list-issues-for-a-repository

It's possible to request issues updated from a date, so there's no problem in caching locally the post and later use meaningful post urls or also use lun.r and have a build-in search engine :-)

formula1 commented 9 years ago

formula1.github.io/

Check it out. We could probably make the login button look a little bit nicer. I'm also considering making the authentication its own module that can get compiled. I'll do a reply to this gist for being so damn helpful with some comments on what helped/what didn't.

piranna commented 9 years ago

formula1.github.io

That's cool! CSS needs some tune-ups (that big avatars... :-P) but it's really great how it's working! :-D

Check it out. We could probably make the login button look a little bit nicer.

I didn't see the login button anywhere. Maybe it's because I'm not using the page intensively and don't get the limit?

I'm also considering making the authentication its own module that can get compiled.

A reusable module, you say? :+1: :-)

I'll do a reply to this gist for being so damn helpful with some comments on what helped/what didn't.

I didn't fully understand how YQL works here, seems to be a online database that does the request in our behalf and has stored the application secret key, so it doesn't need to be exposed, isn't it? It's a shame that OAuth requires a server to be involved due to that, having the token should be just enough, but if there's no other option... :-/

formula1 commented 9 years ago

Avatars

You should have seen it before!

Login Button

If you want to get a 403, go to one of the articles and refresh until it gives you an error. From there, it will show up as "403, try logging in" sort of thing.

Its own module

Yeah, I'll try to tidy it up as a resusable module. That will probably happen tomarrow though.

YQL's involvement

So YQL is an online database, true. However, techinically the table can be specified as just running a script (similar to yahoo pipes). The client secret is technically not secure. If someone decided to brute force select * from yql.storage where name="BRUTE_FORCE_HERE" they could eventually get your client secret. So the secret is dependent on yql generates keys, the speed non-important keys are being created vs whether they know the yql key generation algorithm and speed of them making bruteforce calls. However, if enough secrets are in YQL, the chances of a successful call also containing a secret becomes better. Essentially, it's likely more work/time than someone wants to spend.

Other improvements

Amoungst the things that should probably be done when it comes to html are

piranna commented 9 years ago

Avatars You should have seen it before!

Maybe I've missed them, previously the post titles were pointing to GitHub. Don't mind :-)

Login Button If you want to get a 403, go to one of the articles and refresh until it gives you an error. From there, it will show up as "403, try logging in" sort of thing.

Now I've seen it ;-) It's shown as an error, this would need some tune-up. Also, it's shown too quickly (about 5-10 reloads), so I think we should go with the IndexedDB thing...

Other improvements

I agree on them.

P.D.: i added you as collaborator of NodeOS so you can push directly to the GitBlog repo, could you be able to take a look so we can join efforts there?

formula1 commented 9 years ago

Absolutely, I'll take a look

piranna commented 9 years ago

:+1:

formula1 commented 9 years ago

I'm currently moving to a new hardrive, but I'm going to try to start finishing this up today!

piranna commented 9 years ago

:+1: mine died last week, so we are in the same stage... :-P

formula1 commented 9 years ago

Just an update on this specific aspect. I looked into jekyll and it seems that redirection isn't possible on wildcards. I was also fooling around with making the 404 page the one page app allowing semantic urls however all 404's give a 404 status code (as they should) and I doubt any webcrawler indexes 404 pages (Which they shouldn't).

Right now I'm going to turn the user system into its own module however I'm fully aware of needing handle the ?_escaped_fragment and change the current urls into #! https://support.google.com/webmasters/answer/174992?hl=en

piranna commented 9 years ago

Just an update on this specific aspect. I looked into jekyll and it seems that redirection isn't possible on wildcards. I was also fooling around with making the 404 page the one page app allowing semantic urls however all 404's give a 404 status code (as they should) and I doubt any webcrawler indexes 404 pages (Which they shouldn't).

I don't fully understand your problem, what do you mind by wildcards? In the end, you could do window.location='/' or something similar...

Right now I'm going to turn the user system into its own module however I'm fully aware of needing handle the ?_escaped_fragment and change the current urls into #! https://support.google.com/webmasters/answer/174992?hl=en

Didn't know os this, it's really cool! :-) Maybe it would be its own module :-P I don't know if there would be some problems with the generation of the static HTML pages for the crawler, but GitHub Pages and Jenkins are build in Ruby and could allow to exec some code to generate them...

formula1 commented 9 years ago

By wildcards I mean globs and regex. Ability to match anything. The idea being that

However, jekyll doesn't support .* matching or * matching so I was planning on using 404 to render. If we were to redirect via 404, it doesn't make too much of a difference

That being said, the base framework is basically done, at this point its about css, maximizing SEO and speed increases.

I don't believe Jenkin's is supported by github page. It seems the special things are here https://help.github.com/categories/github-pages-features/. I considered doing some redirects however that would mean I would have to make a page for every possible number. Some additional customization is here http://jekyllrb.com/docs/configuration/.

I was also attempting to setting the source of the site to the /_site directory so that I may avoid a difference between production and development sources however You cannot change the source setting

Jekyll is very simple in what it offers. I could potentially fork and try and build glob support in urls to point to a single file (since they allow globs to be supported in includes/excludes but specifically said they don't want regex not once but twice). But I want to get back to my other projects asap.

As such,

formula1 commented 9 years ago

I'm handling the important stuff for google here https://github.com/formula1/NodeOS-Blog/blob/master/html/footerjs/blogsingle.js#L1

So this can be closed unless you had somethng else in mind