carbon8

Web applications don't need to have heavily designed UI elements. The kind of designer that's useful for a web application is one who has a deep understanding of the unique constraints and conventions of web application design, not someone who is a whiz is Illustrator or screen printing.

Web application design (which is distinct from brochure web design or print design) has unique conventions and constraints, and web application designers absolutely must have a deep understanding of both. There are header nav bars. The branding with the link to the root path is in the upper left, user info/settings are in the upper right. HTML and CSS are structured as boxes within boxes. Main content areas contain the primary content, sidebars contain secondary content. Components are modular. Browsers have significant variation in how they render things, and viewport sizes vary dramatically. We have views and forms, GETs and POSTs. Resources are nested, with one URL per resource. Browsers have different levels of CSS support, leading to a focus on progressive enhancement and graceful degradation.

Every single time I've ever worked on a web application with a designer who didn't know HTML/CSS or a web designer who only does brochure sites, they stumble on these issues, and we end up with inflexible designs that have usability issues and are a pain or impossible to implement. Designers who don't know HTML/CSS create drag in a startup environment. It forces others to spend time and energy explaining how the web works and what the conventions are.

All of this is why the minimum viable product approach can be so valuable. In many cases, you absolutely do not need to make a huge number of decisions before operating. Treat the business as a largely blank canvas. There's a core idea, so put that out there and start experimenting.

Don't worry that you don't have all the features of a similar or competing business that's been operating for a couple years. Don't worry that you don't have everything figured out. In the kinds of business we most frequently discuss here, it really doesn't matter. You will make mistakes (and even your most competent competitors will, too). You will tweak. You can pivot. Most importantly, you can grow.

In fact, as far as reading is concerned, the primary advantage of the codex over the physical scroll was, conversely, also the main advantage of scrolling over pagination on the web: the ability to easily jump to any point in the text.

The issue is actually that it takes time to load the application code and dependencies, something that applies to Django, Rails and just about any similar framework, regardless of whether it's the production or development environment. In general, the production environment will actually be faster at this.

Just to clarify the context to future readers, I deleted by post because I wasn't interested in discussing django, but since you responded I'm addressing it. My original post pointed out that in my experience it indeed does take time to load django and linked to this post: http://stackoverflow.com/questions/1702562/speeding-up-the-f...

Also, since you asked :-) I would question #5. Auto admin libraries (and this applies to multiple languages and frameworks) are generally heavy, too general and have code hidden away in the library. In contrast, banging out crud views and controllers in a locked-down namespace is easy, only relies on same dependencies as the rest of the app, can be customized for the specific business needs and all the code is in one obvious place.

Using too many gems is an problem for a lot of reasons, though. You are introducing dependencies that you then need to manage and update, they often do more than you need to while being harder to maintain (you might end up with a bunch of forks in your gemfile as things get outdated), they are sometimes invasive and will require big rewrites to switch from.

"it seems people in the community get overly excited about something that saves 5 characters"

I agree (though I'd modify to to say "some people in the community"), I just find that I don't encounter it much when I'm following best practices myself.

If you use autotest or watchr you aren't starting up the environment very frequently.

Long startup times or not, sounds like you should probably be using autotest or watchr. 20-30 seconds is not normal. Unless the app has a very large amount of code and dependencies, that sounds like an environment issue.

"while most "Rubyists" would rather pollute the namespace"

That's unfair, and I say that as someone who is very adamant about clarity, explicitness and simplicity in my apps. In my experience, most (not all, but most) of the libraries where people are doing weird things are libraries that are far from necessary, so avoiding that is trivial.

For instance, you cite metawhere. First, I haven't investigated the implementation in depth, but, FYI, it doesn't appear to use method_missing at all. Secondly, I'd be very hesitant to include a library like this in an app, regardless of the implementation, since it's too invasive of a dependency.

The thing you'll run into with that approach is that no authors of gems and plugins that include AR models declare attributes as accessible, effectively assuming that mass assignment is enabled and resulting in the gem/plugin not saving properly. I've had to fork and submit patches for every hugely popular gem with AR models I've used, so it appears practically no one else follows this approach in production apps.

I strongly suspect that leaving all attributes mass assignable on all models other than generated user models is extremely common in Rails apps and it's very likely that this vulnerability is ubiquitous.

This is a very bizarre statment. How can someone write haml without understanding HTML and CSS? How could that even be possible? Haml is little more than classes, ids and element names.

In my experience as a Ruby contractor I've seem many, many more WTFs in erb than haml, to the point where when I join a project using erb I now brace myself.

In my current project I take it a step further. I get the CSS from a designer, dump it in an scss partial, include that partial in the main sass/scss file where I then override and add styles. That way I can keep their CSS versioned and untouched while being able to automatically combine it with additional styles into a compressed CSS file.

The point is that there are plenty of ways Sass is incredibly useful even if the main CSS person doesn't work with it directly.

Obviously Coffeescript is a little different, but the advantage is that a Javascript developer is a programmer and it's not an unreasonable expectation for them to be able to get up to speed on Coffeescript.

We started hosting the Monday Jelly Chicago meetups this week and had a packed house. Next monday following Jelly some of the people here are starting a Startup Evanston meetup http://www.meetup.com/Startup-Evanston/ One of the members here also hosts the well-attended monthly Chicago Web Pros meetup in Evanston http://www.meetup.com/chicago-web-pros/

The startup I'm with is technically based in San Francisco, but I'm actively looking to find another developer in Chicago. If you are a Chicago-area Ruby developer, my email is in my profile.

    stylesheets
      - ie.sass
      - master.sass
      patials
        - _base.sass
        - _forms.sass
      utilities
        - _custom_mixins.sass
      vendor
        - _facebox.scss
        

The nice thing about sass is that it you can change output format, so you can just include all the external CSS files as partials and automatically output a single compressed files with your entire CSS.

When I work with a designer who uses CSS I use a structure like this:

    stylesheets
      - master.sass
      partials
        - _style.scss
      vendor
        - _facebox.sass

Not true. In Rails, sensitive information like database passwords or AWS keys are not stored in the source, you store them in configuration files, YAML files by default. It's also widely recommended that these not be checked into version control.

Be that as it may, in Ruby you should also follow conventions, write readable code, use the most obvious choice when possible and avoid being unnecessarily clever. Most of the core principles that Python promotes should also be heeded when writing Ruby code. Ruby gives you the flexibility to choose different options, but that doesn't mean that the flexibility should be abused.

Edit: found the explanation for the last one: http://www.aimred.com/news/developers/2008/08/14/unlocking_t... So, basically, it's just using it as a normal case equality operator and you generally shouldn't use it in place of a regular #call.

If your requirements fit within what Sinatra can provide, you shouldn't hesitate using it. It's a very straightforward framework and works well. If your requirements are more complex, look at Rails or Padrino, the latter of which is built on top of Sinatra and is actually pretty awesome.

Coffee shops, which are more profitable but also not usually a huge money makers, can make money from walk-ins and, due to the lower upfront prices, require less commitment from each customer. There are a few hybrid coffee shop/coworking spaces, but it's unclear how viable the model actually is. Commercial espresso machines are very expensive ($10K-$15K+), barista salaries are an additional expense and you need to balance serving people who walk in with the people who are on the coworking side. Also, if you have things like enclosed booths that means you have to fit in fewer people per square ft.

So, there's often a market there, but the economics are such that it's hard to make it very profitable, certainly much harder than many other businesses. Still, just so this doesn't sound completely pessimistic, it's not much work to maintain a straight coworking space (not much more than a regular office), it's entirely possible to make enough money to offset the work you put into it and there is a lot of value that extends beyond the immediate financial compensation.

http://coworkingevanston.com/

http://desktimeapp.com/spaces/92-coworking-evanston

We "officially" open on Monday, but we are already functionally open and a group of us have been working out of the space for about a month. The picture above only shows one small section. It has open shared spaces, a small lounge, a collection of private offices and meeting space. If you are a north Chicagoan, stop by!

Coffee shops are great, I really love working out of them and we have some awesome ones in the area, but I needed a change. IMO, coworking spaces can do a good job of having the positive atmosphere of a coffee shop while also being conducive to actually getting work done and they make it easier to connect with people working on similar things. It's also a great way to crowdsource an awesome office for people who otherwise would be working in more isolated environments.

Anyway, to any Chicagoans looking for a nice coworking space, check out Desktime: http://desktimeapp.com

I'm currently opening a 2500 sq ft coworking space in Evanston, IL (http://coworkingevanston.com/). The website isn't updated yet and we are still building out one of the private areas, but we are already fully operational in the main spaces (http://desktimeapp.com/spaces/92-coworking-evanston). Even before officially opening we already started developing a nice community of developers and designers. If you are on Chicago's north side, in Evanston, the North Shore or anywhere else in the area, drop by (600 Davis, 2nd Fl).

    [1,2,3].map{ |x| x * 2 }

    transform = lambda { |x| x * 2 }
    [1,2,3].map(&transform)

Proc calling is built directly into the language via the yield keyword and it's by far the most common way to call Procs.

More importantly (and annoyingly), if I define a top-level method with def—let’s call those top-level def methods (TLDMs)—Ruby won’t let me pass it as a block to any other method.

First, you can indeed pass a method as an argument using &method(:method_name). Secondly, it's rare to pass around named methods in Ruby (http://news.ycombinator.com/item?id=1141245) because Procs/blocks are flexible enough to make it almost always unnecessary. See also: http://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-orie...