by brynary on 10/24/13, 2:39 PM with 31 comments
by ianstormtaylor on 10/24/13, 7:05 PM
- Let open-source projects still live under an account, instead of being weirdly separated. Just oauth with Github and automatically lint all of my repos. I definitely wouldn't mind getting an email for all of them. You're making way more work for yourself by splitting open-source vs. private, when I don't think you gain much. Companies will still have to use the private system. Look at Travis for a better example of how to do this. This is critical to me using the product, I don't want to have to remember the link to these things every time.
- Call it "open-source" not "OSS". Unnecessary abbreviations are confusing. I don't ever refer to it as "OSS", but I'm sure the people who do still understand "open-source".
- The other benefit to letting me actually have an account for open-source things is that I don't have to see the annoying marketing bar all the time when visiting my own repo.
- Even though that solves the marketing bar, get rid of the marketing bar. It's by far my most hated "feature" of most sites, and I would feel pretty comfortable saying that since your target audience is developers most of them probably aren't fans.
- The other benefit is that the ignoring patterns don't need to be migrated over, they're just there. (You'll see this pattern a lot, because separating open-source out is a bad abstraction in your app's design, so it will lead to tons of other random problems and extra work. I'm literally doing this right now for Segment.io -- moving from "projects" that exist by themselves to "users" and "organizations" that contain them.)
- Have an option not to lint. The linter options are really strict, I use a very lax version of JSHint in Sublime, but I don't use .jshintrc because I don't want extra bloat files in my repos.
- It seems like every time I want to add a new open-source repo I have to navigate to the pricing page a click a tiny link... (If I'm actually able to have an account for open-source projects, that wasn't clear at all from the landing page, it looks like signing up is only if I want to pay for a private team account.)
- Add a link to your homepage on your blog. (The old classic.)
- Don't make your min-width so wide. I mean I'm a dev with a huge monitor and still I had to open up my window to not feel claustrophobic. No page in your app needs to require that much space. Cutting off source at ~80 characters is perfectly fine. (Actually, lots of your internal pages could benefit from having less space instead.)
- Make your climate badge look nicer. Travis's badges are disgusting, so no need to copy them exactly ;) (Retina would be nice!)
- If the "view on github" button is important (I think it is) then make it look important. I had no idea what it did until clicked it because the icon doesn't communicate much. (Plus that "g" is from their old wordmark.)
- The search by class name, badge and tweet button are all different sizes so they feel very awkward next to each other.
- The site is really slow. It takes ~5 seconds to navigate from the feed page to an individual file by pressing the graph. And around 1 second to "view more" on the snippets of code. Generally this just makes me frustrated and less happy to use the product. (The importance of this is often underrated, I know because our own dashboard has this exact problem.)
- Come up with a layout that doesn't need to have the repo name overflow with ellipsis. That's pretty much one of the most important pieces of text on the page, so it's not okay to truncate it.
- Get a yellow with more orange in it for "C". Then it would be possible to still use a white letter. This way your highcharts graphs don't break since the labels are all white there.
- Be more consistent with your color scheme. The greens and yellows on the tour page aren't the same as the in the grading. And they're also different from the colors in the source view. And they're different from the colors in pricing?
- Heyo! Just found the "Solo Plan", op, nope that doesn't solve my problem nevermind.
- There's probably a more understandable way to organize the table of files by the way they are nested in the codebase. you might want a sort of Github file navigator instead. Or at least files that are in the same folder shouldn't be bisected by files that aren't.
- I have no idea what the complexity numbers mean. Or the duplication numbers (is that lines of code duplicated?) Or the churn numbers. Or what "C/M" means. Or the smell numbers. Or why smell is a category, since aren't all of these code smell? Should it be lint instead?
- Having a file navigator would eliminate the need for paging the files. (Really strongly suggest a file navigator because it will feel very nice to browse the same way as on Github. I don't need to see every single file up front. I can just browser through my repo like normal. And then the bad ones are called out on the feed page.
- The refresh button is also confusing, why is the commit shown? (I know why now, but in its current state it's un-obvious, slash ugly.)
- Don't abbreviate "Complexity per Method" to "Complexity / M" just to then have a tooltip on hover that says "Complexity per Method".
- Lines of code count seems broken. Lines of code per method also just shows exactly the same as LOC, which also seems broken. Same with method count. (for https://codeclimate.com/github/segmentio/analytics.js/lib/in...)
- Breakdown over time graph is probably better visualized as a percentage-based stacked area plot.
- Churn vs. quality seems pretty useless to me. Can't think of why that will help.
- GPA is a really bad metric. My co-founder asked (is a low GPA good? because the connection to school GPA isn't clear) Just give me an overall grade like "D" for the repo instead. You can still plot the real number over time but I don't need to know about it.
Hope some of that helps! The product seems very promising. The actual (non-lint) smells it finds are usually pretty good from what I can tell.
by cocoflunchy on 10/24/13, 5:44 PM
by bergie on 10/24/13, 3:48 PM
by richthegeek on 10/24/13, 5:33 PM
Most of my projects are CoffeeScript residing in /src, compiling into an identical structure in /lib.
I tried it with a small project, and it only picks up the index.js (which is an example script):
https://bitbucket.org/bithiive/authio-js-client/
Any ideas on what is going on here? Perhaps the "avoiding minified files" is getting in the way?
by gavingmiller on 10/24/13, 3:25 PM
by scrabble on 10/24/13, 4:45 PM
It's also given me the thought that a site where people can sign up to submit code for review and have their code reviewed by someone, which might work well for single developers or very small teams.
by nonchalance on 10/24/13, 5:31 PM
For browser-based scripts, usually a minified and an unminified version are made available. That unminified version is usually the product of a script that concatenates other, smaller scripts. This leads to a perceived high level of duplication (because, after all, they are the same functions and code). For whatever reason, even in private mode, the exclude patterns are not followed.
Also, the linter is much more aggressive than jshint/jslint (in many cases, for no good reason). For example, in a function whose sole purpose is to do bit twiddling (interpreting a set of bytes as an IEEE 754 double), the linter complains `Unexpected use of '&'`. (the original line was `c3 = (e3 & 3) << 6 | e4;`). Akin to JSHint flags, there should be flags to control the linter.
by Segmentation on 10/24/13, 5:05 PM
Edit - I think I found it, once realizing the URL matched Github. https://codeclimate.com/github/jquery/jquery
by moondowner on 10/24/13, 6:34 PM
http://www.sonarsource.com/products/plugins/languages/javasc...
by woutr_be on 10/25/13, 8:09 AM
by etler on 10/24/13, 11:30 PM
by ethanazir on 10/24/13, 9:02 PM
by elwell on 10/24/13, 6:51 PM