I've been thinking for a while now about building a system like this. There is one particular set of traffic lights on my commute which causes 45-60 minute delays at peak times. I've wondered how some small changes to timings of the light might reduce some of that, and was thinking about building something to simulate it and test my theory.
The other thing that is interesting about traffic patterns is how truly connected the entire network of roads are. You can have a collision on a major road which has a big impact on roads several miles away. I've always thought it would be fun to visualize that somehow, to determine not just the immediate effects of a change to a road system, but how it effects other commuter routes.
Definitely going to play around with this. Kudos to the author.
While I also find the surge of electron-based application somewhat amusing, you can't deny that it has made it easier for more developers to develop cross-platform applications without having to develop and manage several codebases with different languages.
I'm working on a side-project at the moment, a large part of which is a desktop application. Using electron allows me to get a cross-platform app out the door pretty quickly. If I had a team of more than one, perhaps I would consider using something else, but as long as it is just me electron just makes sense.
IThat's cool, didn't realise it was the same author.
I understand. The other side of that coin though I guess is that knowing this might give some more confidence in using diesel. ActiveRecord was the first ORM I used, and knowing now that diesel is "from the same stock" (for want of a better phrase) gives some extra confidence in what it can do / where it is going.
Yeah I think at the start there is a lot of value in just starting, perhaps without even finishing. It's that stage of just getting over the first hurdle and getting into it.
That's fine for a while but then as you say you get to the place where you have to finish. I think this can be almost as big of a hurdle as starting as it can involve a whole host of new challenges, some of which you've mentioned above.
Finishing is also, in my opinion, typically not as exciting. You've likely already solved all the intersting problems and are left with the "lesser" tasks involved in getting it over the line. This is something I've been learning myself over the past year or two.
Totally agree. What I've found too is that once you actually start and get /something/ down on the page (or whatever the medium) you actually find yourself getting into a bit of a productivity flow. It might start off bad, but I find I quickly slip into actually getting stuff done once I get over that initial paralysis.
> What's your advice for indie hackers who are just starting out?
> Honestly my single piece of advice would probably be to stop looking for so much advice. Shut the fuck up and go and build something.
I like this. I see a lot of people, and I fall victim to this myself, over analysing the best way to do X, rather than just trying it and learing / adapting as you go. I think there is some value in figuring things out up front, but not at the cost of never taking the plunge.
Yeah! I was surprised by the amount. When I read things now about compiler speed, I'm looking through a different lens now that I have an idea of the sheer amount of work it's doing. Pretty impressive.
> I'm curious how someone made this outlandish claim sound plausible.
From the article:
> Soviet television had, up to that point, been regarded by its audience as conservative in style and content. As a result, a large number of Soviet citizens (one estimate puts the number at 11,250,000 audience members) took the deadpan "interview" at face value, in spite of the absurd claims presented.
I guess this had something to do with it? If people were used to TV being a certain way, and this "interview" was presented in the same way, then it would seem reasonable that it would be taken up in the same was as every other. Nothing (aside from content) made it stand out from other shows.
Saying that, the claim is crazy, and it does seem strange that it was seemingly accepted as truth. I wonder how a similar stunt could be attempted today, and what the reaction would be...
Something I'd love to see is an overview of what parts of the source tree are responsible for what. As a new contributor to projects, that's the part I find takes the longest. Figuring out what modules do the things that I want to work on.
The guts of servo seems to be the the "components" directory. Is there a place that gives some information on each of the components in there?
Not related to the app, but the website. The main text above the app store buttons is really difficult to read, the contrast is quite low. Perhaps darken the text a little?
Well, shit. Finally I feel justified for never (read: rarely) using the "Save password", feature in my web browser.
Does anyone know if Apple have done anything towards resolving this in the 6 month window they requested? Slightly worrying now that this has been published without a fix from Apple. I don't really download apps very often on my Mac, but probably won't for sure now until I know this has been resolved. Annoying.
I've been thinking for a while now about building a system like this. There is one particular set of traffic lights on my commute which causes 45-60 minute delays at peak times. I've wondered how some small changes to timings of the light might reduce some of that, and was thinking about building something to simulate it and test my theory.
The other thing that is interesting about traffic patterns is how truly connected the entire network of roads are. You can have a collision on a major road which has a big impact on roads several miles away. I've always thought it would be fun to visualize that somehow, to determine not just the immediate effects of a change to a road system, but how it effects other commuter routes.
Definitely going to play around with this. Kudos to the author.