People throw out the word feminist without actually thinking about what it means. http://en.wikipedia.org/wiki/Feminism - What does this have to do with feminism? The site doesn't claim that women don't have equal rights when it comes to start-ups.
Interesting idea but I would have a huge aversion to giving anyone equity who I haven't had some experience working with in the past or I don't see as having a long term role in my company.
Would anything change your mind about that? If you wanted to test a hypothesis for a risky business idea and didn't want to sink cash into it, would it be worth it?
Would you prefer a method to pay cash for labor instead?
I think in any potential business venture the team is so critical that I'd go out to people I know to help, even for early prototyping. Admittedly I might not be your target demographic because I can code myself.
As a PHP developer I've been waiting for the web-dev group to jump on board with Python 3 before I make the switch. I'm hoping it will be sooner rather than later.
I'm setting aside the question of whether or why to switch. I'm also setting aside the possibility of starting to learn now on Python 2.7, which is what I think you should really do assuming you don't intend to procrastinate it ;)
Assuming you do want to wait on Python 3 adoption, your timing should depend on the framework you want to use, because effectively each one has its own community and ecosystem, and their adoption is at completely different rates.
If Pyramid looks good to you, for example, it already is on board with Python 3. Bottle is on board with Python 3. If you want to use Django, which is what most people will want to do, you should just wait on Django to release a Python 3 version, and Django should be usable on Python 3 within the year. If you want to use Flask (considered the closest analogue of Ruby's Sinatra) then it could take a while.
I see a couple mentions in this thread of Flask taking a while to adopt Python 3. I am relatively new to Flask, could you explain why they are seemingly behind things in regards to Python 3?
Few core developers (mainly, one, Armin) that couldn't be bothered enough. It's a volunteer project after all.
He did write about the unicode problems with the Python 3 changes and the need for an improved WSGI spec (heck, he even co-wrote the unicode literal change PEP).
But after the new WSGI spec was out, and the u thing was already implemented in 3.3 pre-release, there was no much motion in Flask, whereas Pyramid, Django and others have already started work.
Even the "When will Flask support Python 3" document has not updated and is 2 years out of date in it's contents.
Regardless of how you feel about PHP, I've spent enough time with it that I can make it work and write good code, quickly.
I do want to switch to another language at some point (I'll leave the reasoning for that out of this discussion).
Why switch to Python 2.7 if it's going to be old in a year or two? Even if there isn't a huge difference between 2.7 and 3.x it sounds like it would be a nightmare trying to upgrade any of the old work that I would have done in 2.7. So either I've got some projects that will be on 2.7 forever, or I go through the hassle of trying to upgrade. I'd rather just wait and avoid the whole debacle.
It's definitely possible (and not really hard), but I understand the mindset: if you're coming from an other platform, why bother with switching when you can wait a bit and just start with Python 3?
Because Python 2.7 is completely mature and production ready and also allows you to write code which runs pretty easily on Python 3. Then you are marking Python 2.7 as deprecated version at the time where before you would have been just getting started.
Really this is down to whether you want to do something in Python now, or you want an excuse not to do it in Python for some time. It's not a bad excuse but it's also not a strong reason to wait.
This is kind of disheartening. I found it on the front page and saved it so that I could read the discussion later. I've gone through the same thought process while evaluating job offers at start up companies and would have been interested to hear the other side of the story from the employers.
It's "free" in the sense that it's not a subscription. Not free in the sense that Amazon pays the provider (AT&T in the US) to provide the access, the costs for which are rolled into the business model -> Amazon's fees from the publisher -> Content prices.
So you end up paying for it in the end, since say, $0.05 of every dollar (totally made up figure) ends up going to AT&T.
So, to coin a somewhat wordy phrase, it's free-as-in-jet-fuel-when-you-buy-a-plane-ticket.
I don't think there's any disagreement about using the right tool for the job. What I took from the original MicroPHP Manifesto is that the solution is not to have a ton of hammers to choose from. Instead, make sure you have a couple different types of hammer heads and a couple different types of handles that you can mix and match so that the right hammer is always available.
This way your toolbox is much lighter and easier to carry around (easier to keep up to date with improvements to the code and easier to maintain). I think it's about breaking things into smaller pieces.
I used to feel this way. However I tended to find myself, on most projects, spending a surprising amount of time tweaking incompatibilities between the various lightweight libraries I was using. And it was a bit of an effort to unify things like logging and error reporting.
Which is when I realised the utility of a bulky framework; for the most part it is a suite of libraries that work together/are compatible but which someone else maintains for me :)
This was a big step for me.
(although I still use the lightweight approach for smaller projects)
That's a reasonable complaint, but maybe it means we need better lightweight libraries with well thought out interfaces or better library management like deweller suggested in the comments on the original thread.
That would be good - but then you begin to talk about a unified logging interface and standardisation like folder structure, class loading, class interfaces and so on.
At which point it's basically a framework (perhaps without the routing/initialisation code).
One thing I would like to see (no idea if it exists) is a core package architecture (that did all of the above) and let you hang packages as and when you need them.
I've been keeping an eye out for such a thing for a while with no joy.
My sister is a designer, but interested in learning how to code. I'll be seeing her over the holidays and I thought the best way to teach her the more technical side of the web would be through a quick hackathon style project.
Here's our pitch for foodwithafriend.com:
It can be hard to keep up with friends from all of your different social circles.
Wouldn't it be great to be able to catch up with a different friend each week over some delicious food? Food with a Friend will automatically match you up with one of your friends each week for a tasty meal at a local establishment.
You tell us what days you're generally free and we'll match you up. Then all you have to do is pick a restaurant!
If we can get 100 people to sign up, we'll build it. Otherwise we might choose a different idea.
