allanderek

I have seen so many versions of this same script. The fact is that such header comments at the top of every file aren't that useful. I mean, what do you use them for? The information in them, is already stored from the fact that the file is under source code control. If someone moves the file from that then that will just increase the chance that the header comment is wrong.

Put another way, have you ever been reading a file and thought "Oh I wonder which project this belongs to and who wrote it? I'll check the top."

I'm afraid I have no real expertise in user-experience so I cannot really say. I definitely think you want, as you suggest, a "How it works" at the very top, centre of the landing page. Preferably in graphic form.

I also still think you want example dreams to be viewable by anyone. I believe that few people sign-up without a good idea of the kind of thing they are signing-up for.

That's a very noble approach, but I don't understand how it relates to not showing non-users current dreams? Is it that you have to pay to even view dreams? I didn't get that from the home page. I think at the very least you need to demonstrate to potential users what the product does, otherwise (I think) few people will sign-up for something they don't really understand.

So in IMHO the fact that this person cannot see any of the dreams prevents them from understanding. If you really do not want to show non-users any dreams, why not just have a couple of made-up example ones?

You cannot seem to view any of the 'dreams' without creating an account. You are going to lose a lot of potential users this way.

You're welcome. Thanks for a useful site. Would you like some code review of the source code done? I'm not sure how much time I'll have in the near future, but I can try?

I like it. The blog site that hosts it has a slightly strange menu, when at 'home' there are three links 'Blog', 'Apps', and 'Contact', when at Apps, there appears to be only 'Blog' and 'Contact', when at 'Blog', there appears to only be 'Contact'.

But the actual app, is great. I like the output, but I would consider sorting them into those dependencies which are up to date and those which are not.

If you really want some extra user-friendlyness and learn a bit of the github API, that would be a cool way to accept input. Instead of copy&pasting the pip-freeze output, how about just your github repository link, you could then search for a requirements.txt (or similar), OR a first effort at this would be to allow users to link to a requirements.txt file, for example one hosted on github.

Finally, what about a spin-off pypi library to do this? I'd love to be able to do this from the command-line inside my project's directory.

This looks great. There are a couple of minor bugs that I've come across so far.

    1. Occasionally at the 'Prompts' screen, pressing the reload icon causes a blank prompt, which means there is no reload icon. Hence the user has to refresh the entire page.
    2. In  the "prompt" screen the place which I think is for some title text from the user does not show what is typed. The user can see the cursor moving, but no text, they can select the text but it is not highlighted. You can select copy & paste the text elsewhere. Suggesting that the text colour is just the same as the background colour.

Other than that, you have small logos in the top right, but the logos are far from clear what they actually do. Home, Settings and (probably) logout are clear, but the other two are not so clear.

It's nice. I like that you don't need to log-in, or create an account, or anything like that to play.

A bit more feedback on illegal moves would be a good addition. Even better would be feed-forward, such as dimming the places that the current chip cannot be placed. With a tool-tip explaining why, even better.

I like the easy way of bumping the version attached to review. That mitigates it to some extent.

So first off, I like this. I actually quite like the design as well. I absolutely agree that a "latest reviews" or something would be great. The first thing I want to do is at least see a single review, just to see what one looks like.

Probably a bit late for you to change since you have your domain name, but the name kind of suggests code reviews. But I don't think you're really aiming for code reviews correct? You're aiming for a kind of package reputation?

A related project shown here as well: https://news.ycombinator.com/item?id=11481459

There I wrote a comment about how package reputation systems have the slight problem about what to do when a package is updated. A review may then be out-of-date, but you cannot just delete old reviews since they may still be quite appropriate. So it isn't an easily solved problem.

The bike itself looks quite neat but this kind of website grinds my gears.

Is it possible to buy one? I could not tell from the website. I'm no customer expert but I guess that many visitors want to know two things 1. is it possible to buy this now? and 2. how much does it/is it going to, cost?

I understand there are several models, but still someone just wants a rough costing. Does such a bike cost the roughly the same as a traditional bike of the same quality or is it currently much more expensive? So, can one such bike be had for somewhere between $500-1000 or is more like $5000?

The lack of any price makes me assume the latter, and I just get out of there before I find out any more information about the actual bike.

Your website is very well designed, to me it looks very nice.

On my browser (Firefox-Linux) if I open the hamburger menu on the right, and click, say, API usage, the content is pushed off to the left and I can't even scroll it back. The only thing I can do is close the hamburger menu to properly see the content.

I was going to give a couple of comments assuming that you were hoping to turn some visitors into paying customers, but this seems to be an entirely free service.

I was going to say that "Python based" is a positive for some and a negative for others. I'm not sure it needs to be in the list of features and surely does not need to be the first feature. What should be first? "Unlimited Users", though not the use of the word "currently" may well put some people off. It suggests that this will not be free in the future, which perhaps it won't be. I don't know.

Secondly, a REST-API is great, focus more on it being something that can be integrated into a developer's application. The others, Python based, Machine Learning, Crafted With Love, Minimum Downtime are not really features at all. Python based and Machine Learning are just implementation details, the first is not really important and Machine Learning is kind of the assumed method of spam filtering. So overall your list of features scream you claiming "This is really good honest", rather than demonstrating that.

The Python API example is good, this is what a Python programmer cares about, they might dig a little deeper and be pleasantly surprised to find the whole thing is developed in Python.

In general, it's hard to see any unique selling point here. Why would a developer use this spam filter over a self-hosted one, or other existing one? I'm not saying there isn't a unique selling point, just that your website does not make this abundantly clear.

I like it. On python-ideas the idea of a curated list of pypi packages comes up from time-to-time. The most recent incarnation was started just last month and you can read it here: https://mail.python.org/pipermail/python-ideas/2016-March/03...

Such discussions usually die out after some people give their opinions on what such a package curation/voting system should be like, whilst others state why we should not have such a system.

For my money, most of the objections are really just people pointing out that it is a very difficult to design problem. Rather than objecting to the actual idea.

So anyway, it's really nice to see some actual working code.

A few of comments:

1. You describe this as the "go-to Python Toolbox", but I'm not sure that really describes what it is well. It's really a summary of github statistics. Even forgetting how the packages are rated, you have a package rating system rather than a single toolbox. I think what you have is more interesting than a single python toolbox.

2. You have not quite solved the major complaint that usually comes up in discussions of such package voting systems. That is, that a package is not generally just "good" or "bad", but appropriate or not appropriate for given uses. Furthermore, I think the 'Popularity' metric is not quite obvious from a first look at, say, a package category. In other words, it's not quite obvious that this is a measure of how the github repository is starred. At least then the user can decide themselves whether or not this is a useful metric.

3. Github stars is not a bad measure. A better one would include the ability to downvote.

4. Pretty much all repulation/voting systems have the problem that for any "votes", or even full-blown reviews, it's not clear which version of the library they are about. This is really difficult to solve. Since you only have positive votes the problem is not so pronounced as it is in other systems (or proposed systems). But the basic problem is that a bunch of users downvote a library because it is difficult to use, or doesn't have tests, or they cannot install it etc. The developer takes that into consideration and produces a new version of the library, what should the reputation system do? It's really not a trivial question. You still have that issue in that a bunch of users may have decided not to star a library because of an earlier version. They may even star a library which later becomes less useful, for example because it is superceded by a better library, or because the code degrades. I understand users can unstar a repository, or flock to a new one, but still, the general problem is not entirely solved. That said, using GitHub stars probably suffers from this problem less than other measures.

5. I really like the look of it. I think the colour scheme for Python is the best of the three so far.

I guess I'm struggling quite to see the use case here. For web-site providers themselves they would much rather do the conditional logic themselves because then that would apply to all visitors not just those that come via your shorturl service.

I can perhaps imagine someone tweeting something like: "I've just published a new book, get it here", where 'here' is a link, which might send the user to the correct Amazon page based on their location (eg. amazon.com for US users and amazon.co.uk for UK based users).

Looks quite nice. For the lazy it is currently IntelliJ, Textmate, Atom, Emacs and Vim. I'm going to guess that adding a new IDE is relatively straightforward depending on how that IDE stores its themes.

I suppose it's a question of how many people switch IDEs etc. If you only use one, then you may as well use the theme-editor that comes with that, even if that is just editing the preferences and then checking. But if you switch IDEs a lot then I guess configuring/storing a theme once is quite useful.

Personally I don't switch much and when I do I'm happy to use different themes for different IDEs. But I'm sure there are others who would appreciate this.

Sounds great. The landing page, which is nice and light with no visual burden on the user. However, it's not quite clear what exactly a user should put in the single input box? The placeholder 'Trendr' does not really help at all. I understand that if the user waits a moment the placeholder changes but even still it's unclear what I should put in there. (Also there is probably some survey somewhere that demonstrates some really high percentage of users wait less than some really short space of time and hence will never see your placeholder text change).

How is this different from say, Flask, Bottle, Route and the like? Basically I think the README could do with explaining a bit better what is unique to Feather. When would you use Feather over Flask or Bottle?

That is of course assuming that you wish for others to use it.

If I'm honest, this is a great example of a home page in which I've browsed it and have no real clue what it does or what problem it attempts to solve.

The cookiecutter project more generally is a great example of a project that started as a small thing for one person's purpose and has grown to be more generally useful.

The screen cast videos did not work for me. Pressing play just made the video load, but would play for only a fraction of a second.

Anyway, I think I about understand the concept. Basically, rather than organise software into files, you store your source code as a database.

This has several advantages. Firstly you can easily attach metadata to your source code components (be they, modules, methods, functions, datatypes, classes, etc.). You can then selectively choose to view/edit the metadata attached to source code components. The traditional way of attaching metadata is to have semantic comments, which quickly tend to get a bit ugly.

Once you have such metadata you can choose which parts of your source code to view on screen. Rather than open a file which may also represent a module or class, you can open a filter, which filters code objects. A bit like labels in email organisation are better than directories, since an email can belong to more than one. To put this another way, deciding how to modularise your program is tough, using a database to store your code objects you could make it a bit less tough by making it more flexible.

In general when you change the format that source code is stored in, you face the the problem that you're mostly stuck with re-implementing all of the software tools that support a language. Okay, so maybe you don't quite have to re-implement all of these tools so much as re-target them, but still, it's a chore. A particularly challenging tool is source code control.

In addition, you have the problem that typically, a project will have to either choose to store its source code in traditional text-based format, or whatever the newly proposed format is. Usually the proposal to get around this is to translate between the two, so that code is actually stored in the original text-based format, but when you open it up with your fancy new format-aware IDE, it does an on-the-fly translation and you get all the benefits thereof.

This might work to an extent to allow users to use existing tools, although you still need to do a bit of touch up, for example, coverage analysis will report on the translated text-based format rather than your database format. So you have to translate the results of coverage analysis, but you can at least get to a point where it is usable in this fashion.

It does not work so well for collaborating with others that are still using the text-based format. Mostly because your database format when output as a traditional text-based format, either loses all the metadata, or stores it as comments, or in a separate meta-data file. These all have the obvious problems when collaborating with someone who either ignores it, or wants to.

Source code control is a problem in both kinds of scenarios. Even if all developers are using your database format, what happens if there is a merge-conflict? Either they have to modify directly the translated text-based format, or you have to implement merge-conflict resolution in your IDE.

None of these problems are insurmountable. They are just challenging.

In summary, I think the reason source-code-as-database has not already been a success, is mostly because it is difficult to introduce incrementally. But I hope you succeed.

I think it's quite a nice idea, but I'm struggling to imagine myself using this. For a start, I want my tests in my source code repository. Secondly, I want to run my tests locally before I upload to production, perhaps even before I write the code to satisfy the tests.

I see that you have also developed a chrome extension so that one could run their tests locally. But that is essentially different from running your tests as a service. In this case you're essentially providing a testing library.

I could just about see myself writing my tests locally (perhaps using your chrome extension) and using the local tests for development and then uploading those tests and using a service to check a production server periodically. But I'm a little sceptical (why not just have the production server run the tests periodically itself?)

There may be some other uses for Web UI Automation as a service, for example scraping.

This is a good point. In particular what happens if you fork a repository, do you lose the meta-data? What happens if you have a fork for coordination of a sub-team, are the pull-request annotations created on that fork also available with the main repository once it is merged in?

This is beautiful and clearly very useful. Some thoughts:

* Business-wise, your main risk is that GitHub agrees how useful this is and builds much of the same features. In a sense, GitHub can improve in this manner, by taking the best features of external services and implementing them directly.

* The killer app here would be if you can integrate this into an IDE. In other words, the annotations are great for code-review, but not just code-review. In general they are essentially better comments. Wouldn't it be great if I saw those annotations whilst coding? I understand that it's not as if you personally could create plug-ins for all existing IDEs. But could you have an API to make that possible for third-parties to author said plug-ins?

* Integrated with code-analysis software could make for a very pleasing automated-code-review service. For example, with Python you could annotate the source with the output of pylint. Obviously, I'm not suggesting that this replaces manual code-review, just that it would be a nice addition. I mean you already have the automated annotations highlighting where a line was affected by a pull-request.

* The tour was really nice, but whenever I was asked to "go ahead and click on the annotation" this did not really work, mostly it just advanced the tour. On that note, it would be good if the tour suggested how far was to go.

I think this is a pretty good idea, sort of reminds of 'hoogle' (https://www.haskell.org/hoogle/) which allows Haskell developers to search for functions based on type.