88 karma · joined June 2, 2010
Sea Foundry is developing hardware and software solutions to address critical bottlenecks in coral reef restoration. We work closely with non-profit organizations and marine biologists throughout the tropics to enhance the efficiency and efficacy of coral restoration.
We are seeking an experienced full stack software developer to join our small team.
Skills and Experience We're Looking For:
- 5+ years of proven experience as a full stack software developer
- Proficiency in React and front-end technologies (experience with Tailwind and TypeScript is a plus)
- Deep familiarity with Rails or similar MVC web frameworks
- Basic knowledge of Python
- Experience with AWS technologies (e.g. S3, EC2)
- Passion for environmental conservation and coral reef restoration
If you're interested email me directly at mike@seafoundry.com
While NFTs can be confusing, over-hyped, or even fraudulent it is clear that they give artists new power. The power to create a scarce resource, prove that they created it, and sell it for substantially more than they could could otherwise sell electronic collectibles. How much of this is due to hype and how much is due to the ability to record and validate the "deed" to the NFT on the blockchain? I think that's an open question that will be more clear over time.
The author also understates the importance of DAOs and smart contracts imo. The real power of a DAOs or smart contracts is not in replacing financial instruments, but in replacing legal ones. I think in a short amount of time it will not be unusual to see wills executed via smart contracts.
I might find myself rapidly switching between framework documentation, developer tools, a preview pane, and a similar piece of code that I'm using as a template. I'm infinitely happier when each switch is an eye movement and not a jarring keyboard stroke that redraws the entire screen.
I'm curious if you're unphased by constant cmd-tabbing.
Feastin is a food company. We believe that concepts like grocery stores and take-out will soon seem quaint. We think distinctions between groceries, prepared foods, meal-kits and take-out will be looked back upon as artificial. We're building a better, more efficient way to deliver food into your home. We launched in the Bay area last summer and are now operating with over 30 restaurant and wholesaler partners.
We're less concerned with your familiarity with the perfect set of tech skills and more interested that you can learn quickly, work hard, and work smart. That said if you have experience with React, React Native, or Rails you should be able to hit the ground running on day 1 and that's definitely a plus.
We're not into high-stakes interviews or grueling take-home tests that you "should" be able to do in a few hours. If after a quick chat w/ the team we think you could be a good fit, we will pay you for a 20-40 hour contract job and decide where to go from there.
Email me directly at mike@feastin.com if this sounds like something that you'd be interested in.
"Fifteen minutes could save you 15 percent or more on car insurance."
https://web.archive.org/web/20111201164345/http://www.the-dm...
http://www.instructables.com/id/How-to-extend-the-life-of-yo...
http://www.amazon.com/review/R3604ULQ9IPQIK/ref=cm_cr_dp_tit...
Allow the page to break if the user's browser does not support websockets If you know that 95% of your target audience uses modern browsers this seems like a reasonable compromise.
Don't write enough unit tests Maybe you're using a library that is difficult to mock. Maybe most of your logic is happening at the db layer. Eventually you may want to thoroughly test this piece of code, but it's a ton of work to mock a database in a meaningful way.
Write a monolithic service instead of a modular one While it's bad to let a single service grow too large, when you're starting out, it can be helpful to write it all out, and _then_ see how it can be broken apart. (It's often hard to foresee everything at the design stage.)
Finally, a lot of code ends up being never used. Nobody cares about well-factored well-tested code that isn't used. Sometimes a dirty version is the quickest way to tell if a project makes sense at all.
From a security and composability perspective, the Docker
process model - where everything runs through a central
daemon - is fundamentally flawed. To “fix” Docker would
essentially mean a rewrite of the project, while inheriting
all the baggage of the existing implementation.Shouldn't the market be a little more excited about this?
I guess I haven't been involved in too many 2-3 year monolithic projects. Maybe that's when a stricter symmetrical unit test policy makes the most sense.
What other levels of tests do you end up running besides your unit tests? Do you have any integrated unit tests? Functional tests? End to end tests?
As a developer that often prefers tests at the functional level, the primary benefit of tests for me is to get faster feedback while I am developing.
Impress.js is a html/css based presentation framework. More info here: https://github.com/bartaz/impress.js