41–50 of 441 posts
Very interesting question because once you solve it, it doesn't seem hard anymore.
My company is building a device which collects data from a car while you drive. We wanted to group those in "trips" on a very simple logic. If the device sends any data for the first time, start a trip and if there's none for more than 5 minutes, close the last trip. Problem was that the source of the time is coming from the device which had a lot of bugs (e.g. time was in future, time is from year 1970, time is not…
> At the end I was able to convince the management that some bugs were too serious and required fixing This was the hard problem you solved, right? How did you go about it?
Eventually I got it working and I could boot DOS and play games.
The aim of my project was to create a programmable emulator that could be used for the semi-automated analysis of malware, and sell it. Eventually this didn't really go anywhere as this was a too ambitious goal to do all by myself. See here [1] for a demonstration where I load tweets from Twitter and send them to the DOS text editor by triggering a keyboard interrupt via a Python API. Fun...
Later, the Unicorn CPU emulator framework implemented my idea much more effectively by creating Python bindings to an already mature emulator (QEMU).
An ongoing soft-skill problem I am learning to solve is the effective customer development.
An interesting UI/UX problem I am currently thinking about is how to allow people to draw sun/shade patterns, wind current patterns, and essentially contour lines that show elevation on their property (the last is to ultimately learn how water flows on their property, and where there are drainage problems) in a fun, minimal-effort way. If anyone has any suggestions on this, please feel free to share.
The last two types of problems are for my side project, AutoMicroFarm.
I was working on a calendaring system. We supported recurring events, and each event could also have a piece of equipment associated with it (one or more). Events could also be changed, either the current event or this and every event. Event start/stop times were stored in UTC, but the event was displayed in the users timezone, and could cross daylight savings time boundaries. This was done with a mix of javascript o…
How did you handle the database storage for recurring events? Did you have just one entry that represents the recurring event as a abstract whole, or a database entry for each instance of the recurring event? The former seems "better", but you also run into a whole lot of complications: 1) The user can delete specific instances of a recurring event. Eg: delete the event for thanksgiving Thursday but leave it intact f…
* UX was hard when people want to change individual events that are also part of a recurring event (who wins)
* daylight savings time is an issue when you store datetime in UTC (you need to shift the UTC value in Nov vs in June to have it be the same "8am every Friday" event)
* saving a change across all of a large number of events created a large, slow transaction that caused slow responses (in some cases triggering heroku timeouts)
I was lucky that we didn't need to implement inviting guests, as that wasn't needed.
There were times when I wish I'd implemented the RFC standard: https://www.ietf.org/rfc/rfc2445.txt but never got to that. (We also evaluated just building on top of Google Calendar, but I was worried about building on top of an API that we weren't paying for, and there was the issue of tying in child equipment events.)
ICOs and DAOs both present difficult legal problems vis-a-vis the SEC and securities laws. Where others have failed we believe we have developed a legal framework for both a non security/unregistered ICO and legal DOA. To legitimize our legal position we submitted a No Action Letter to the SEC. Uniquely this is not just another legal article/arguement, because the SEC will not respond to a hypothetical No Action Lett…
I'm 33 now. Ill come back in 20Y time. I don't believe I've encountered my hardest challenge yet
Earlier quoted context omitted.
How did you handle the database storage for recurring events? Did you have just one entry that represents the recurring event as a abstract whole, or a database entry for each instance of the recurring event? The former seems "better", but you also run into a whole lot of complications: 1) The user can delete specific instances of a recurring event. Eg: delete the event for thanksgiving Thursday but leave it intact f…
I have worked with recurring events, and the answer that I've seen is generally both. You have one record which is the "template" and then populate the database out with specific instances to some arbitrary date. Every so often then run a cron to populate further and further out.