61–70 of 441 posts
I went from a software engineer to starting my own CBD company. Most of what I do is sales now. Making the transition has been very difficult. It's a completely different world.
What have you learned and what was difficult?
Capital?
Good sources for CBD or are you producing everything from scratch?
I recovered the redacted text in this image: https://btcblockchain.files.wordpress.com/2015/02/e2.png
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…
File under "things programmers assume about time". It kept doing "weird" things from the user perspective and I ended up writing more tests for that subsystem than anything else I've ever done.
These are typically problems that involve interaction with very complex meat-space concerns.
One of the hardest challenges I have had in my career is convincing our company to move to Continuous Delivery. 90% of the challenges weren't technical, but emotional. Shipping software comes with lots of feelings, fear, politics, etc. I had to personally work with various leaders across the org to help them through these feelings and perceived blockers. We aren't 100% there yet, but we are shipping numerous times pe…
That is interesting because I am still trying to figure out how people do CD. Of course I know CI, we have it all set up. But we still work in sprints with manual testing and release every 2 weeks. I could spend time on marking features 'frontend only, low impact' which we could deploy pretty much the same day. Still there are quite some features that need bigger amount of work where they might be 'done' by dev but I…
* Every PR is treated as "production" ready. This means if it isn't ready for user eyes, it gets feature flagged or dark shipped. Engineers have to assume their commit will go into prod right away. Feature flags become pretty important * Product Owners and QA validate code is "done" in lower environments (acceptance or staging, or even locally during PR phase). This helped us decouple code being in prod and "definition of done" in our sprints. * All API changes and migrations follow "expand and contract" models that makes the code shippable. e.g. even if we are building new features, we can ship our code at anytime cause the public api is only expanding. * More automated quality checks at PR time. Unit tests, integration tests, danger rules, etc. These vary from codebase to codebase. A key part of this is trusting the owners of that code or service. To a degree, if they are happy with their coverage, then they can ship. (Within limits of course. Not having unit tests at least would be a red flag)
Also, we still ship numerous times a day without a full automation test, we just make sure each release is really small (1-3) commits. The smaller the release the easier it is to manually QA it. So nothing fancy is needed, just smaller releases.
So to answer your question, we don't pick and choose work that is "low" impact or "high" impact, all code gets shipped the same and with the same cadence. It is our responsibility to ensure that when it goes to prod, it won't break anything
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…
On load/view time, generate events from the list of defaults and amend with the exceptions as needed. The user should not see the default/exceptions system, just events and the pattern.
I’d say working with exceptions in this way is more efficient than storing many copies of the same event.
I recovered the redacted text in this image: https://btcblockchain.files.wordpress.com/2015/02/e2.png
How did you approach this problem and solve it?
So what I would do is:
1. Estimate the possible locations of spaces (e.g., using OpenCV).
2. "Guess" certain letters based on what is visible above and below the black bar; these are your constraints.
3. Look up dictionary words that meet the constraints found in (2).
4. Loop through steps 1-3 to build a list of possible seeds.
5. Run these seed candidates through Electrum.
I should add that I never really solved it, as the solution didn't work very well.
I started with the glimmer of a hope that perhaps network sync could be made stateless, went down a months-long rabbit-hole of research, and ended up writing a novella-length article about CRDTs: http://archagon.net/blog/2018/03/24/data-laced-with-history/ So many days spent thinking, sketching, trying to swallow a concept that seemed far to big for my jaws—only to suddenly find myself on the other side, with this ar…
I found it a few months ago, read it through the end, and shared it with my team. It's the best survey of synchronization techniques that I've come across.
I recovered the redacted text in this image: https://btcblockchain.files.wordpress.com/2015/02/e2.png
How did you approach this problem and solve it?