A little improvement in the RubyInstaller site

[MarcRic]

Hi Luis,

In another topic I have suggested a modification in the way the site deals with the release notes for each version.

I'm in vacation right now and think I have a chance to help into this field.

To start that task I need from you two things:

1. Update the https://github.com/oneclick/website-html with the complete site, including sub-pages.
2. Tell me where I can find or how to search in the list the current and previous release notes.

I think I can make a revision in the following items:

• Upgrade it to HTML5.
• Review (and possibly improve) CSS
• Include an intermediate "release notes" page before each attempt to download

Or any other of your interest.

Regards.

[Luis Lavena]

On Wed, May 16, 2012 at 10:05 PM, MarcRic <mar...@gmail.com> wrote:
> Hi Luis,
>

Hello Marc,

> In another topic I have suggested a modification in the way the site deals
> with the release notes for each version.
>
> I'm in vacation right now and think I have a chance to help into this field.
>

That is awesome!

> To start that task I need from you two things:
>
> Update the https://github.com/oneclick/website-html with the complete site,
> including sub-pages.
> Tell me where I can find or how to search in the list the current and
> previous release notes.
>

Back in January I emailed the list:

https://groups.google.com/d/topic/rubyinstaller/O5JS4jCwJio/discussion

Which covers both the new website codebase, the reason why the change
was required.

Current Website implementation is with Radiant. The original HTML no
logner applies/work directly so you need direct access to the Radiant
installation.

I would rather prefer invest your time on the new website so release
notes can be handled more easily.

I believe, except for the static pages and the archives that things
are more descriptive with it, but please let me know.

>
> I think I can make a revision in the following items:
>
> Upgrade it to HTML5.
> Review (and possibly improve) CSS
> Include an intermediate "release notes" page before each attempt to download
>

As commented above and the thread I linked, editing and improving both
HTML and CSS inside Radiant is very hard.

> Or any other of your interest.
>

Your contribution to any extend will be highly appreciated.

Thank you.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[MarcRic]

OK Luis,

That way I will need to rethink everything...

I was thinking in a static site up to now.

So, I understand You think Radiant didn't fit our needs, let me know why.

Considering all this, I feel that a Rails specific project will fit our needs. Do you confirm that?

Give me some time and I will return to you.

Regards.

[Luis Lavena]

On Thu, May 17, 2012 at 1:42 PM, MarcRic <mar...@gmail.com> wrote:
> OK Luis,
>
> That way I will need to rethink everything...
>
> I was thinking in a static site up to now.
>

Sorry, it wasn't

> So, I understand You think Radiant didn't fit our needs, let me know why.
>

As explained in the thread I linked, there are lot of manual steps
that Radiant makes it hard to deal with.

> Considering all this, I feel that a Rails specific project will fit our
> needs. Do you confirm that?
>

Rails is too much, why? If you see the most dynamic parts of the
website are already covered in the repository I shared.

Why you want to rebuild it with Rails? Don't understand. A simple
sinatra application can deal with it.

[MarcRic]

Luis,

Being strictly honest.

Rails is my current (in fact from a few years), priority learning subject.

Since I'm a half century developer, I have limited space in my brain, so, to make long story short:

At work, I need to deal with Java EE and all sort of derivative knowledge needed...

At home, I have decided to focus in only two:

Ruby (with some incursions in Camping) and Rails.

I have nothing specifically against Sinatra, I just prefer not to use my limited brain space on it.

I'm not even sure, if I can conduct the project up to the end, but for sure I can start it in Rails.

Would be nice hear from others in this list if they have skills to more properly contribute if the project is being conducted in Rails or in Sinatra.

Regards.

[Luis Lavena]

On Thu, May 17, 2012 at 2:56 PM, MarcRic <mar...@gmail.com> wrote:
> Luis,

Hello,

> Being strictly honest.
>

Good,

> Rails is my current (in fact from a few years), priority learning subject.
>
> Since I'm a half century developer, I have limited space in my brain, so, to
> make long story short:
>
> At work, I need to deal with Java EE and all sort of derivative knowledge
> needed...
>
> At home, I have decided to focus in only two:
>
> Ruby (with some incursions in Camping) and Rails.
>
> I have nothing specifically against Sinatra, I just prefer not to use my
> limited brain space on it.
>
> I'm not even sure, if I can conduct the project up to the end, but for sure
> I can start it in Rails.
>
> Would be nice hear from others in this list if they have skills to more
> properly contribute if the project is being conducted in Rails or in
> Sinatra.
>

I appreciate the honesty on this, so I'm going to be honest.

What you're saying is that what I worked on (the base of the new
website) is useless and you're going to start (with no promise to
completion) a new Rails-based website.

Since you're mentioning that you're familiar with Rails and not
Sinatra (and not wanting to learn or use it), means that the YAML
information of each reach most likely will not be used by you, and
instead something in the realm of ActiveRecord DB-backed solution is
the suggestion.

If that is what I understand, then I feel I wasted my time in my
attempt to create a smaller and simple solution that avoided the
overhead of Rails and was still clear (in most pure-Ruby as possible)
what was required to be done.

The goals of having a simpler YAML-based configuration is that I can
generate that YAML file programatically with each release, commit on
the website repository and easily deploy to heroku/EC2/whatever.

If I need to consider managing releases, uploading files through the
web/cms then we are just changing the tool but still dealing with the
same problem: automate and reduce human and manual time required for a
release.

I don't want to discourage you, but if you think you can build what I
did on the prototype I linked before on Rails and make a bit more of
progress to cover like front-page or the archives pages I think others
(including myself) will be able to complete it.

Regards,

[MarcRic]

My Turn. (a lá Tony Stark)

I appreciate the honesty on this, so I'm going to be honest.

What you're saying is that what I worked on (the base of the new
website) is useless and you're going to start (with no promise to
completion) a new Rails-based website.  

As I understand now the current site is already made in Rails.
Radiant is a Rails project right, but seems like a configurable CMS project it has much more functions then needed and is not so configurable as should.

Since you're mentioning that you're familiar with Rails and not
Sinatra (and not wanting to learn or use it), means that the YAML
information of each reach most likely will not be used by you, and
instead something in the realm of ActiveRecord DB-backed solution is
the suggestion.

 

In fact I'm studding Rails, and being interrupted many times forced by other (my work) needs, but keep trying.
My recently return brings me another (smarter in my point of view) way to start Rails projects.
It is not a "model based" way but a "view based" one.
I have just Googled for how to import YAML files into databases and find at least a dozen Ruby related answers.

If that is what I understand, then I feel I wasted my time in my
attempt to create a smaller and simple solution that avoided the
overhead of Rails and was still clear (in most pure-Ruby as possible)
what was required to be done.

In my opinion there is no work out there that can be considered a waste of time. We are always learning.
I still think that a Rails specific solution should be so small and easy as we decide to get it done.
Of course, if compared with others like Sinatra, Rails is an overhead,
But strictly to the facts. If instead of trying to adapt a CMS project to fit our needs, we define our needs and use Rails to get it done, it will not necessarily be an overhead.

The goals of having a simpler YAML-based configuration is that I can
generate that YAML file programatically with each release, commit on
the website repository and easily deploy to heroku/EC2/whatever.

 

What if part of the logic when including a new record in the "releases" table is reading the YAML file programmatically and include its content in the appropriate field?

If I need to consider managing releases, uploading files through the
web/cms then we are just changing the tool but still dealing with the
same problem: automate and reduce human and manual time required for a
release.

 

I'm considering your needs our needs, We have been  benefited by your work all this years. So, if you say that generating Release notes pro programmatically in YAML files is the the easiest way now, we will need to consider that in the final solution. No question about that.

I don't want to discourage you, but if you think you can build what I
did on the prototype I linked before on Rails and make a bit more of
progress to cover like front-page or the archives pages I think others
(including myself) will be able to complete it.

 

No not yet discouraged.
I think we can discuss and start prototyping the views ASAP.

And keeping Saint-Exupéry's thought in mind:

Perfect views are those from witch is nothing more to take way!

Regards.

[Justin Baker]

Rails is my current (in fact from a few years), priority learning subject.

Since I'm a half century developer, I have limited space in my brain, so, to make long story short:

At work, I need to deal with Java EE and all sort of derivative knowledge needed...

At home, I have decided to focus in only two:

Ruby (with some incursions in Camping) and Rails.

I have nothing specifically against Sinatra, I just prefer not to use my limited brain space on it.

Sinatra is actually pretty slim and minimal. For a site like rubyinstaller.org it's actually

much more simple than a Rails application.

I suggest you take a look into some Sinatra code. I think you'll be pleasantly surprised in the simplicity

of a Sinatra app in comparison to a full blown Rails application.

Also if you understand how a Rails app works, you can probably figure out a Sinatra app pretty easily.

I'm not even sure, if I can conduct the project up to the end, but for sure I can start it in Rails.

Would be nice hear from others in this list if they have skills to more properly contribute if the project is being conducted in Rails or in Sinatra.

In my opinion, a Sinatra app is a better use case for rubyinstaller.org 

The conventions of a Rails app would be more of a problem to work around than a easy framework

to benefit from.

Of course, I enjoy diving into the Rails source and looking around. So I see use cases that are meant 

for the complex situations that people might use Rails for. But there is probably a better way to rewrite

rubyinstaller.org than I would do it.

I say if you want to try it, then try it. Even if it's a wrong idea, completely useless, or is actually more 

complex(I've been guilty of doing this on several occasions); you will probably have learned something.

But I still think that looking at Sinatra is also something you should consider. I think learned more 

Ruby idioms and good practices from trying to write a Sinatra implementation than I did from writing 

the actual Rails app on one of my side projects.

Also, most of the rubyinstaller.org site is written in pure ruby. There is only one file 'website.rb' that

has any Sinatra DSL in it. And if you look at it, it basically looks like a Rails controller merged with

Rails routing.

Finally, not to throw a hamper into this whole rewrite discussion, the changes

that you are suggesting are mainly view changes.

I think I can make a revision in the following items:

• Upgrade it to HTML5.
• Review (and possibly improve) CSS
• Include an intermediate "release notes" page before each attempt to download

With the exception of a single new resource(intermediate release notes), these are all

HTML and CSS changes. The CSS is just a plain .css file in the public folder, and the

HTML templating system is still erb and still structured a lot like Rails views(minor caveats).

So I don't think you need to learn anything outside of Rails knowledge for these. The first two

upgrades you can just dive in and treat like erb and css, and the third I guarantee we 

would be more than happy to write a route for you if you needed us to.

If you need any help diving into the code, let us know. =)

Justin

[MarcRic]

Hi Justin,

I have been looking to the code in the Sinatra project and see that the HTML is already prepared for HTML5, and if the corresponding CSS files fits the current needs there is nothing to do there concerning my two first upgrade suggestions.

I will need some time to make something by myself and present to you both.

Regards.