it's using ratatui and built in Rust :)
HN user
AdamMeghji
Co-founder & CTO, Peggy.com e: first_name at peggy
it was not, so that's a mistake that's been fixed, thanks!
apologies, those broken links are misleading (docs coming soon, but not open source atm). Removed.
totally fair point! the medium/long-term roadmap is to layer in a BBS-esque community, so identity is required. more on this later! regardless, might be nice to have an unauthenticated / "Skip sign in" flow for the folks who just want to use the tool.
https://sampler.meiji.industries/
I built a TUI sampler which cherry-picks my favourite features from modern & vintage hardware samplers, DAWs, plugins, outboard FX gear, and DJ equipment.
If you know what an AKAI MPC Live, MPC 3000, SP404, SP1200, BOSS RC-202, Alesis 3630, Serato Sample, S950 filters, and stem separation does, then you'll love seeing these "greatest hits" up in a terminal interface.
Last year while on vacation in Costa Rica, I started scratching my own itch for locating and organizing samples, which quickly evolved into adding more and more features while keeping it tactile and immediate. It was too fun to stop so I kept going. After a few days I was happily making beats in it, and since then it's only gotten better.
It's live and totally free to use, and works in macos & Linux (Windows soon). I'm about to launch v1.0 now, just working with folks in the community to round out the Factory Kits a little more for users new to beatmaking.
Turns out, making beats with no mouse and a terminal interface strikes the perfect balance of hardware feel and software power, and I'm loving the result. Been sharing it with folks in my beatmaking sphere and have plans to continue expanding its reach through more collaborations, contests, and in-person events.
Hope it brings you as much joy as it does to me :)
Awesome. Do docker image layers persist across build runs? Github, BuildJet, etc. use ephemeral runners, so subsequent runs have to re-pull everything from scratch, which is where most of my actions' time is spent now. If you're able to persist these across runs, that'd be a reason to switch alone.
Congrats on the launch! I've spent some time recently with great success speeding up CI for my teams via alternate actions runners, and the increase in efficiency that comes with dramatic reductions in build times is worth it. When the cost is the same (or less), it's an absolute no-brainer.
How do you differentiate from BuildJet, which takes a similar approach?
A big motivator for going the EUC route was a) the wheel is a huge 18" tire and 3" wide, so small potholes and roots/branches are no problem, thus safer, and b) having a EUC w a suspension means I'm less likely to be bounced off, even less so if you add some "power pads" that support the upper foot area. Check it out!
Electric Unicycle. For short trips and errands, it's a super fast and effective way to zip around my area. For more recreational trips, off-roading on local trails and ravines is super fun. It feels like snowboarding around the city, and has a learning curve of a few days (like skiing). Initially, I borrowed an old one from a friend and decided to stick with it by getting my own (a fairly good one). Next up was the various safety equipment. You could spend anywhere from $1500-4000 on the unit + safety gear depending on how fancy you want to go. Even a minimal base model that's a few years old would be totally fine.
Peggy | Principal Mobile Developer | REMOTE | Full Time | https://peggy.com
Peggy is the social marketplace that allows you to discover, buy, and sell art. We partner with art galleries and artists to onboard their artworks, register a secure digital fingerprint for each artwork, and connect them to our vibrant collector community. Our art fingerprinting tech also enables the ability for collector-to-collector resale, which creates liquidity that was previously only accessible to billionaires selling Blue Chip art via auction houses. Best of all, we do right by our emerging, contemporary, and living artists by paying 5% artist royalties on each resale transaction.
We're hiring a Principal Mobile Developer for our iOS and Android (flutter/dart) app. You will be partnering with our design, backend, and technical leadership teams as we drive towards our exciting alpha release. You possess expert-level mobile experience in any of: Flutter/Swift/Kotlin/Java/React Native. If you're a seasoned mobile developer without Flutter experience yet, no worries, we've found that experienced polyglots pick it up very quickly.
Peggy is a remote-first company. We are building the company this way so we can curate a team with the best talent from anywhere in the world, and to create flexibility for team members. Team members currently/recently working from: Toronto, Vancouver, CDMX, Brazil, Argentina, London, India, Sweden, Lisbon, Madrid, NYC.
Peggy | Senior Back End Developer - Ruby/Rails | Full-Time | REMOTE: US, Canada, Global*
Peggy partners with galleries and artists to make living with and investing in art accessible to all. Finally you can buy incredible art at a price you can afford, and can later sell to fellow collectors if your tastes change or you seek to rebalance your art investments. Core to our values, Peggy does good by the artists themselves, who can finally earn artist royalties for all future secondary sales as well - something they miss out on today. This is all made possible using sophisticated and proprietary AI and ML which keeps buyers and sellers protected without the need for the antiquated and opaque Auction House model.
As a key member of the back end team, you will be responsible for providing an elegant and well-documented GraphQL API as an entry-point into Peggy’s content, data, and business logic, which is crafted in Ruby, Rails and Postgres. You will be supported by a DevOps infrastructure, which leverages AWS, Terraform, CI/CD, CloudWatch, Auth0, Sentry, and other developer-friendly tools and systems.
Peggy is a remote-first company. We are building the company this way so we can curate a team with the best talent from anywhere in the world, and to create flexibility for team members. Team members (incl. ex-Shopify, Uber, Ada) currently/recently working from: Toronto, Vancouver, CDMX, Brazil, Argentina, London, India, Sweden, Lisbon, Madrid, NYC.
More @ https://peggy.com/careers?ashby_jid=bcf449d8-38d0-49d7-aca6-...
*: Global timezone preference within [ GMT-8..GMT+2 ]
Is this possible in MacOS at all? I have an RX100 V and an Elgato Camlink HD, but would love to use that capture card w another cam, and use the RX100 over USB simultaneously.
The combination of this HTTP Load Balancing announcement, and May 23rd's announcement of CoreOS support are super exciting. I've been working on setting up a similar docker-based multi-AZ autoscaling setup on EC2, but getting it up and running has required integrating a lot of separately moving parts. If Google can simplify this process via a few simple gcutil commands and a cloud-config YAML file, it would be a hugely compelling offering.
Install the tools you need via the Dockerfile (iostat, top, atop, etc.), and an sshd. Then, instead of running the single web process, run supervisord via CMD, which will subsequently launch both your web app process, AND sshd. From there, EXPOSE 80 22, and you can SSH into the container to run any perf analysis tools as usual.
EXPOSE 80 22; CMD ["/usr/bin/supervisord"]
We're using pacer-neo4j (https://github.com/pangloss/pacer-neo4j) at Uniiverse with great success embedding neo4j within a jruby 1.7 webapp. I'd definitely suggest checking it out as well!
I also used this brief window of opportunity as a fun experiment in learning Ansible. As a result, I've published a repo which automates setting up LTC mining on g2.2xlarge instances.
http://github.com/adammeghji/ansible-ltc-mining-on-ec2
If anybody's curious to spin up a GPU instance and dabble with this, this greatly facilitates downloading, compiling, and installing the CUDA drivers, and setting up the LTC miners. Amazon has a $100 credit available too, if the current spot instance prices are prohibitive.
Based on AWS spot instance pricing, LTC mining difficulty, and the present value of LTC, it can be profitable to mine for LTC on EC2 g2.2xlarge instances.
This project was inspired by Bob Feldbauer's post on Profitable LiteCoin Mining on EC2, and a desire to practice my Ansible chops.
As of right now, the spot instance price is approx $0.30/hr, so it's no longer immediately profitable, so I wouldn't recommend this if you're looking to flip a quick buck (before yesterday would have been a different story). Nevertheless, a fun weekend hack project if anyone's curious to give it a try!
My version of the logo: http://imgur.com/Laxvw7E
The logo is the wheel on a cassette, which is a fun throwback to the tape days, inspired by TAR -> Tape ARchiver.
While not exactly a Barista, our bootstrapped startup invested in a DeLonghi EC702 15-Bar-Pump Espresso Maker for approx $175 USD on Amazon.com. We'd usually make Starbucks runs and spend $2.50/trip once or twice a day, so it didn't take long to pay itself back.
But more importantly, it's been a fun for us developers to try and hack our little entry-level espresso maker into pulling the best cup possible. Toying with the variables that go in to pulling a tasty espresso (quality of grinds, grind fineness, tamping, duration of pull, etc.) has become an on-going project here, and our espresso rituals are now baked in to our culture.
So yeah, definitely recommend "hiring a barista", even if it's just a DeLonghi EC702 15-Bar-Pump Espresso Maker.
I listen to Rinse.fm (http://rinse.fm) incessantly for 8+ hours a day, it's got some of the best DJs in London for dubstep, house, grime, reggae, and everything in between. Always a solid listen.
Otherwise, usually anything instrumental. B.Lewis, Apollo Brown, and Pretty Lights have some great instrumental albums out now which cast a positive and productive vibe on my hack sessions.
Oh, and people apparently enjoy coding to my instrumental album! :) http://djmarmalade.com (free download, shameless plug).
I'm in.
Adam here. Actually, we're with Rogers because they've got a discount available for condo residents, so it's better value than Teksavvy, all things considered. I'm a huge Teksavvy fan and have them at home as well! But we opted for the Rogers deal instead.
The all-inclusive condo option is an interesting idea as well :)
Regular ping pong matches was something we originally wanted to do, but now it would require moving our monitors, laptops, all-in-one printer, etc. and that's just too much work! hehe.
If I had to add an 11th point, it would be "SSDs should be mandatory". I've found a huge productivity increase since switching to one, and will never go back to anything else for the primary disk on my development machine. That said, we're bootstrapping, so not everyone has one _yet_ ;)
I'm a co-founder at Uniiverse (and the guy coding up a storm in the photo for #2!).
I will agree that yes, we go to extremes when budgeting for food, please understand that _budget_ has very little to do with the _quality_ of food that you can eat when you're bootstrapping. Truthfully speaking, I'm eating more healthy, tasty, and cheap meals than I've ever eaten in my life. As a former "lazy programmer" who would opt for a morning bagel + cream cheese for breakfast, then a fast food lunch, and a restaurant dinner every single day (usually keeping an empty fridge at home), I'm much happier with my meals than when I had plenty of budget for food. Oh, and I've lost weight in the right places too :) Food can be wonderful at any budget. Plus, restaurants taste so much sweeter when you're taking $0.00/yr salary :P
Design-wise, myself and my co-founders are more than capable of fully designing & coding a sufficient application skin / theme, and we started out with that route, but the results we got by going with our "top-notch design shop" were far superior and well worth the investment. Design is extremely important, and not something we wanted to skimp out on. Spending the extra few dollars up front for a kick ass design is something that can have an immeasurable positive long-term impact if done right.
I've been using Titanium for 2 months now while developing a prototype version of our iPhone application (Android later), and while I share the author's sentiments on a number of issues, I'm fairly pleased with the results so far. I'm not an Objective-C guy in the least, but am reasonably good with JS, so it's a great way to go native.
That said, some comments: - JS Warnings. It's true that one-line ifs, property existence checks, function closure suggestions, etc. can get a little annoying. My solution is to write JS which is 100% JSLint compatible, which is fair IMO.
- Titanium Warnings. These get annoying. I get dozens of "[object TiUIView] has an auto height value of 0, meaning this view may not be visible" warnings which are completely useless and don't identify the offending View for me to fix. Also, I get about a dozen errors like "<Error>: CGContextDrawImage: invalid context 0x0" which give me no indication which is the offending image. Etc.
- Performance. While native, our application runs a little sluggish and certain views are choppy when scrolling, and some style properties have bizarre rendering behaviour (layout: 'horizontal', width / height: 'auto', etc)
- Minor Revisions. The author is right, some minor revisions introduce pretty bad issues. 1.6.0 introduced some very noticeable performance degradations in TableViews, so we're still on 1.5.1 for now.
- Documentation needs work. The API reference is lacking any mention of certain parameters, which is frustrating. The wiki has more detailed information and has essential reads to understand things like TableViews, but I didn't find this resource for several weeks into my project. Many undocumented side-effects exist, like quirky behaviour on horizontal layouts, etc. Here's an example of the kind of confusion which results: https://appcelerator.lighthouseapp.com/projects/32238/ticket... The "headerPullView" feature for pull-to-refresh is currently undocumented magic.
- Barcode support is disappointing. Titanium+ introduced Barcode support, but does not support the usual 1D barcode. The additional libraries that exist (TiBar, zbar, etc.) are very difficult to compile in without XCode hackery, and sometimes don't work on the devices themselves, making debugging very difficult.
- Bugs in XHR with Content-Type and passing Arrays, requiring workarounds when integrating with Rails. Arrays get sent as "( key1: value1\n key2: value2\n)\n" .. seriously :)
- Titanium Developer required me to click "Launch" to start the application until I read Gene Tsai's comment on the original article which gives you command-line aliases to start your application. Awesome tip :)
At the end of the day, Titanium Mobile is a great solution, but be prepared to be patient while the platform matures, and to get creative in architecting alternate solutions when your initial approach doesn't work. I'm confident the wrinkles I point out above will be ironed out in time.