How to insert Kickstrap in a larger project

[Gabriel Naranjo]

Hi:

We used Kickstrap 2.xx to build IA prototypes with great results. In that use case we would make a Kickstrap installation in a directory inside our repo and start working from there.

The new kickstrap is huge: with an initial payload of 45mb, 1 hour installing modules, and around 324Mb when installed, I do wonder if all of the members of our team need to have the whole kickstrap in each machine in order to work on the backend of the project (wich falls outside the work is being done in the backend, for instance)

@ajkochanowicz: what would you recommend in this case, should I set this up outside my project repo? I'm using OSX Yosemite

[Adam Grant]

In terms of set up, one of the reasons why kickstart is so large is simply because of the repository. You're downloading a lot of the history of the kickstart project, even though you don't really need it.

To get around this, what you could do is use the depth flag when cloning the repository. This would allow you to clone it with only one or a few steps back in history. Here's an example:

    git clone ./ --depth=1

This makes the cloning a lot faster, but it also means keeping repository up-to-date can be problematic. I experienced issues with doing pulls on a shallow clone (The technical term for using a clone with the limited depth). 

Other than that, two best answer your question I would need to know a bit about your set up. Are you running this as a gulp project, jekyll, or using the rails gem?

—
Sent from Mailbox

On Wed, Feb 25, 2015 at 11:10 AM, Gabriel N [e-mail]
wrote:

Hi:
We used Kickstrap 2.xx to build IA prototypes with great results. In that use case we would make a Kickstrap installation in a directory inside our repo and start working from there.
The new kickstrap is huge: with an initial payload of 45mb, 1 hour installing modules, and around 324Mb when installed, I do wonder if all of the members of our team need to have the whole kickstrap in each machine in order to work on the backend of the project (wich falls outside the work is being done in the backend, for instance)

@ajkochanowicz: what would you recommend in this case, should I set this up outside my project repo? I'm using OSX Yosemite

Reply to this email directly or view it on GitHub:
#176

[Gabriel Naranjo]

Other than that, two best answer your question I would need to know a bit about your set up. Are you running this as a gulp project, jekyll, or using the rails gem?

Thanks a lot for your quick answer @ajkochanowicz:

I used roots with version 2.4 of Kickstrap, and usually the work was a precursor for a PHP template or application. I don't particularly have any preference on either gulp, jekyll or rails. I used to just write roots clean; roots watch and be done with it. But with version 3 I do get bogged down in the docs by having to select a technology before doing anything. Please review the way the docs for Bootstrap are written: rendering technology comes last, easing you into the different concepts of the system.

The nice thing about Kickstrap 2.xx for IA prototypes was that it provided a starting point, the possibility of not having a blank slate, and a number of associated technologies that helped you code faster —Jade, Stylus, CoffeScript and Bootstrap, among others—and each came with their own helpful and well written docs. I realize that the new version has lost that, not even having bootstrap integrated, but that took time, because even the About page— the one that tells me that bootstrap got the shaft—is last in the site, at the very least should be second after Home.

The documentation has suffered, it has no clear path to follow and not many examples—at least for non-coders with experience assembling complex design projects— regarding a number of aspects that the old docs had embedded within: If you are speaking about Layout , the logical thing is to go on to Grids, not continuing with naming conventions, components, jumping to design aspects of CSS —colors and such— and then going back to Grids. I'm lost already.

The design of the docs also affects the experience: it is way too confusing to have navigation > explanation > code and all the white gaps that this layout generates. Please consider designing the docs in one column with a small side navigation, and including more examples with the results shown

Kickstrap 3 may be very good and powerful, but I think is trying to go too far for the level of documentation that it currently has. I will stick with V2.4, my devs are going to hate me if I begin coding prototypes with V3 as it is.

[Adam Grant]

My general impression here is that the backend team would only need to have the CSS file that is output from kickstrap but none of the node dependencies or less files. 

Of course this would mean adding the built CSS to the repo which has some code smell, but it would allow your backend devs to ignore the build process and the wait required to install everything. 

—
Sent from Mailbox

On Fri, Feb 27, 2015 at 5:20 AM, Gabriel N [e-mail]
wrote:

Other than that, two best answer your question I would need to know a bit about your set up. Are you running this as a gulp project, jekyll, or using the rails gem?
Thanks a lot for your quick answer @ajkochanowicz:
I used roots with version 2.4 of Kickstrap, and usually the work was a precursor for a PHP template or application. I don't particularly have any preference on either gulp, jekyll or rail. I used to just write roots clean; roots watch and be done with it. But with version 3 I do get bogged down in the docs by having to select a technology before doing anything. Please review the way the docs for Bootstrap are written: rendering technology comes last, easing you in the different concepts of the system.
The nice thing about Kickstrap 2.xx for IA prototypes was that it provided a starting point, the possibility of not having a blank slate, and a number of associated technologies that helped you code faster —Jade, Stylus, CoffeScript and Bootstrap, among others—and each came with their own helpful and well written docs. I realize that the new version has lost that, not even having bootstrap integrated, but that took time, because even the About page— the one that tells me that bootstrap got the shaft—is last in the site, at the very least should be second after Home.
The documentation has suffered, it has no clear path to follow and not many examples—at least for non-coders with experience assembling complex design projects— regarding a number of aspects that the old docs had embedded within: If you are speaking about Layout , the logical thing is to go on to Grids, not continuing with naming conventions, components, jumping to design aspects of CSS —colors and such— and then going back to Grids. I'm lost already.
The design of the docs also affects the experience: it is way too confusing to have navigation > explanation > code and all the white gaps that this layout generates. Please consider designing the docs in one column with a small side navigation, and including more examples with the results shown

Kickstrap 3 may be very good and powerful, but I think is trying to go too far for the level of documentation that it currently has. I will stick with V2.4, my devs are going to hate me if I begin coding prototypes with V3 as it is.

Reply to this email directly or view it on GitHub:
#176 (comment)