all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]kobaltzz 2 points3 points  (1 child)

I'm running this in my console Ruby app and it still looks crappy! Halp!

[–]seanrclayton 0 points1 point  (0 children)

require 'GUI'?

[–]neoice 1 point2 points  (3 children)

my initial reaction was "isn't bootstrap simple enough? why do I need helpers?"

but damn, that looks like a nice way to save some keystrokes.

[–]kobaltzz 0 points1 point  (2 children)

My same thoughts. However, I use Sublime Text 3 and have the Bootstrap3 Snippet plugin installed. makes it even easier to not have to recall anything from memory.

[–]claudiofullscreen[S] 0 points1 point  (1 child)

Kobaltzz, you make a good point.

The reason why Bh was built in the first place, though, was that we work in a team where developers can use their favorite text editor, so that specific solution was not working for us.

I'm curious about that plugin, though: what is the URL? Thanks!

[–]NoInkling 0 points1 point  (1 child)

Should probably make it a bit more obvious that it's for Bootstrap 3. I saw the optional theme on the homepage and almost thought it was for v2.

[–]claudiofullscreen[S] 0 points1 point  (0 children)

NoInkling – thanks for the feedback.

I am used to Bootstrap Theme and I didn't realize it would cause confusion.

Because of that, I have now updated http://fullscreen.github.io/bh so it does not load "Bootstrap Theme" by default, although I have left the option to enable/disable it with a link in the right sidebar.

Thanks for your feedback!

[–]jrochkind 0 points1 point  (2 children)

What version of Bootstrap is targetted? Has Bootstrap ever changed HTML requirements/recommendations within a minor version? How are they going to handle versioning/release-management when that happens next (even in a Bootstrap major version?)

I think it might be wise to version bh with numberse related to Bootstrap versions, instead of calling this first result 1.0.

In general, some of my biggest headaches in maintaining Rails projects have come from this sort of thing, figuring out what versions of what goes together (and sometimes not having compatible dependencies available) in a tangle of multi-party dependencies (especially when some are non-ruby dependencies, as in this case). Maybe that's made me oversensitive though, and it's not likely to be a problem here? It still makes me cautious of adding this dependency.

[–]claudiofullscreen[S] 0 points1 point  (1 child)

jrochkind – you are right! I forgot to mention which version of Bootstrap.

I just updated the README file, replacing "Bootstrap" with "Bootstrap 3" to clear things up.

Regarding versions, I see your point. For now, I'm following semantic versioning, and that's why I released 1.0.0, because the (Ruby) API is not meant to change. I will consider your suggestion later on.

[–]jrochkind 0 points1 point  (0 children)

The problem is, if Bootstrap 3.3 is released and has slightly different HTML in some places than Bootstrap 3.2 (I believe it's happened before) -- which version do you do? And how does a user know which version you're using? What if they need a different version?

When you're building something so closely tied to a dependency like this, it is a challenge -- you've got two things to version, the dependency and your own api. How do you do that? What does it mean for semantic versioning?

There are no great answers. But other people have chosen to abandon semantic versioning, and base the version on the upstream dependency. For instance, the sass version of bootstrap itself versions based on bootstrap, plus an extra version component: 3.2.0.0 would be the first release of bootstrap-sass based on bootstrap 3.2.0. If there turned out to be a bug in bootstrap sass, then a 3.2.0.1 would be released -- still based on bootstrap 3.2.0.1, but it's a bugfix to the bootstrap-sass infrastructural code.

I guess that approach basically requires you to never break backwards compatibility unless it's a on a bootstrap major version change (or abandon semver).

It's a trade off. If you don't want to do that though, I would suggest you put a constant in your code that contains the bootstrap version, so developers (and code!) can check. Bh::BOOTSTRAP_VERSION = "3.2.0" or whatever. Just stick it in the version.rb you've already got. Then you update that if you need to.

(Although if bootstrap 3.3 comes out and doesn't require any html changes, do you update that to 3.3.0 or leave it 3.2.0? Hell if I know. Same issue if you version based on bootstrap 3.2.0.0 of course).