Hacker News new | comments | show | ask | jobs | submit login
Making Pulled Pork with React Native, Expo, and Express (daveceddia.com)
210 points by dceddia 37 days ago | hide | past | web | favorite | 94 comments



The takeaway piece at the end really hit-home for me:

    I think it’s important to work some fun into programming projects.
    Give yourself permission to build something that already exists,
    if only to learn how to build it yourself. It doesn’t have to be
    a big serious project, or a perfect portfolio piece.
    
    And on that note, don’t be afraid to hack things together. It’s
    a fun project! Write some terrible code that you know is terrible.
    Don’t stress so much about perfect abstractions and Best Practices
    and feeling like you have to incorporate every new library and tool.
    It’ll be fine. You can always refactor it when you write the blog post ;)
I can't even count the number of similar, fun projects I've started... but which turned into stress centers that felt more like chores than leisure, causing them to never be completed. Often I end up worrying about the "best" way to do something or start planning for when the project is huge and needs to be well formed; paralyzed before I even get the code working.


Because it's frustrating af to read block text on mobile I'm just copying over your pull quote.

----

I think it’s important to work some fun into programming projects. Give yourself permission to build something that already exists,if only to learn how to build it yourself. It doesn’t have to be a big serious project, or a perfect portfolio piece.

And on that note, don’t be afraid to hack things together. It’s a fun project! Write some terrible code that you know is terrible. Don’t stress so much about perfect abstractions and Best Practices and feeling like you have to incorporate every new library and tool. It’ll be fine. You can always refactor it when you write the blog post ;)


Not all heroes wear capes.


It's frustrating to read it on the desktop too! Thanks :)


Damn, yeah. Same here. That little voice of "is this really the BEST way" has grown stronger and stronger over the years, and I kinda have to fight it back to "allow" myself to do little hacky projects like this.

I always wanted to be better at software engineering, and software design, and getting abstractions right, and all that stuff. I've slowly gotten better at all that, but I didn't know it would come with the tradeoff of being unable to switch it off.


That ability to switch it off is very important. A couple months ago, one of my co-workers was asked to do something quickly for an important customer. I would normally be the one to work on that codebase, but I was busy with something else. I gave him some suggestions, made it completely, crystal clear that hacks were allowed since the customer needed it by the next day at the latest and it only had to run for a few hours and we could use the excuse that it wasn't under version control if they wanted changes later.

He's a very good engineer and this was well within his ability, but he became hamstrung by the hackiness. He continually complained that it would be unsupportable (I know), that he would be asked to make changes (no: this was explicitly part of the agreement with the customer) and it was a bad design decision (yes!).

By the time 4 o'clock rolled around, he had made little progress on his well engineered and future-proof solution and I didn't want to be there late, so I offered to take it from him, finished the hack by 4:30 and pushed it to the customer.

Customer loved it; greatly appreciated that "we had dropped all our work to put two engineers on their project" and it did exactly what they needed to demo their own product.

I guess my point is that engineering is about getting stuff done. Sometimes, if you know time is more important than anything else, your only choice is either cut corners or don't ship. Being a day late can be the same thing as never shipping in some cases.


I agree with your approach here. However, there's one interesting problem we always run into with that approach and it's what causes the discontent, I think.

It's when something that is being designed and built with the intention of a short lifespan ends up being around for a long time, and causing problems for longer than it was intended to exist at all.

And I think this happens all the time.

I think you did the right thing (I would have too), but unless you have solid consistency, work ethics and a great memory, you may put in that quick fix and it never gets improved.

If the quick fix stands the test of time, then it was the right fix regardless of how fast it was done.

I guess that is why I have grown into the approach over the years of always.. ALWAYS checking expectations thoroughly, even when it hurts a little.

It's important in the early stages of problem analysis to know - 1) how long do I have to analyze the problem? 2) how long do I have to implement a solution to the problem? and 3) how long does the solution need to last? Of course there are a million other questions, but I think it needs to start there. Of course, while answering those questions, as a service function, we must always be thinking... hands down.. what is in the best interest of the customer (which can be subjective, but it must always be the forefront)?

If you are given constraints for those 3 things, you can more accurately come up with an appropriate solution. My experience with this is hard-earned from just doing and always having to get creative.

Sometimes, I plain ask people - do you want a long-term solution, or a short-term solution? If you can come up with 3 options quickly based on your experience - short/mid/long-term and give the pros and cons, I've found most business users like this approach. Some prefer to just be given an answer and have the issue handled immediately - however, that isn't always the best for them nor the people doing the work. But, as they say, sometimes it comes down to "needs must".


There are few things as permanent as a temporary solution.


When I see yet another “# TODO: this a hack, it’s doesn’t really work but we’ll fix it asap anyway” I like to make bets with myself as for what date I’m going to see in git blame. Today I’ve replaced one such 3yr old todo with another todo that someone else will probably discover three years from now. The reality...


I think if you're a profitable company some percentage of engineering effort should be carved out for continuous refactoring. I'm sure there is a good balance in there somewhere.


it's one of the biggest weaknesses that engineers/programmers/logical, problem-oriented thinkers have. doing something quick and hacky when it doesn't need to be flawless just feels so wrong. you miss that feeling, that rush when a perfectly-engineered solution just snaps into place and works like magic. and that becomes a problem when it begins to interfere with deadlines, like in your story.

i think that's a big part of programming as a career, learning to know when to make something run flawlessly, and when to make it just... run.


Ehh, the problem here seems to be less about logic and more about misaligned priorities in the context of business. There’s a lot to be said about the dopamine rush of making a client happy!


> learning to know when to make something run flawlessly, and when to make it just... run.

Or learning that user has a very different meaning of flawless, and that is almost always the more important definition.


Trying to bootstrap my own startup and doing all the engineering on my own money my engineering philosophy has changed dramatically. Where I used to be guy A, I'm now very much guy B.


nothing like financing yourself resources to understand that time indeed is money


In those cases it should be documented that it is a have and also limited in scope so that other stuff doesn't really on it. If it's a small one off, no biggie.


THIS.

Mediocre now beats great tomorrow more often than not.


I saw a diagram once from an MS programmer, I wish I could find it - it was the evolution of code... and it went something like:

Totally Crap -> Less Crappy -> Just Crap -> Starting to get half decent -> Actually not too bad and working -> EOL


> Mediocre now beats great tomorrow more often than not.

This reminds me of Patton's Law of Program Planning from Akin's Laws of Spacecraft Design[1]:

> 33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.

[1] https://spacecraft.ssl.umd.edu/akins_laws.html


Engineering is not about “getting stuff done”, but what you’ve described isn’t engineering. The word is thrown around too loosely in the software world.


Probably thats why many programmers have many great ideas but fails to come into reality. They cannot gain any fun from side project since they automatically want to ‘learn’ new framework, language, etc. Instead of messing around and looking how their idea grows into something fun. Its about having fun from creating, not from learning the proper way since beginning. Its clear when you tell your friends about your new idea - they would say ‘oh thats sounds cool!’, but when I tell the same to my programming friends I would rather hear ‘you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem, so it doesnt make sense’


IMHO, after enough years, it becomes less about wanting to learn the new framework etc. and more about wanting to actually accomplish a specific thing.

Put in another way of saying it, when you get tired of the constant pace of change of our toolsets, it becomes more about the problem and solution rather than the specific tool you use to solve it.

Don't get me wrong.. I still do love learning all the latest and greatest, and keeping my hands on the tools. But over time, after a long time of getting distracted (or even disrupted by the "need" to keep learning new stuff), I feel at least that it can get tiring and to the point of interrupting any actual productive labor towards a bigger goal. So I agree with you.


You nailed it. It stops being 'wanting to' and starts being 'having to' and that is a subtle inflection point in an engineers life.


Switching it off is how you learn to switch it on better.

I started a react project a few years ago and opted against Redux and whatnot. As the project grew and grew it became harder to maintain. Piece by piece, I self identified a 'best practice' that would solve a real problem I had.


Yeah, fwiw, I am pretty good at avoiding too many shiny toys (though this project might not be a good example of that).

I'm all about using React without Redux when it makes sense, and especially at the beginning of a project. Heck, I wrote a whole book teaching React that way, and it's how I learned it myself. Wanting to use the "best practice" libraries is a different angle than what I meant though, which was more like a background thread running in my mind about how I should be refactoring things as I go. Two sides of the same coin though, in a lot of respects.


I think it depends on the purpose of the project. If it's something that you actually want to finish soon, I think this is great advice. Having said that, there is nothing wrong with using a side project as a way to find out what the "best" way to do something is. I personally have an ongoing side project that I will likely never actually complete because I rewrite large parts of it every couple months, but I have learned a LOT about various design patterns, how best to structure code, etc, precisely because I use it primarily as a place to experiment with code. If you don't see the finished product as the end in and of itself, then I don't see anything wrong with that.


Something I went through recently was discovering that by doing the 'wrong' thing first - that is, ignoring 'best practices' and doing the 'easiest' thing to achieve the job, you discover the 'best' way more organically. Even if you end up following the same best practices you ignored initially, you are able to appreciate and understand them more.


Do stupid things, because sometimes they really do work.

And if it's stupid and it works, it's not stupid.



Oh hey, that's the girl that makes the crazy awesome robots. I didn't know she had a TED talk. Just Googling and realized she recently had a brain tumor and underwent surgery! Luckily sounds like she's recovering well. https://twitter.com/SimoneGiertz/status/1003470270189858816


I organized a "bad ideas hackathon" at work last year, and it was AWESOME to start with the premise that we were deliberately setting out to build bad ideas. It freed everyone from the shackles of perfectionism, and the teams came up with a whole bunch of devilishly terrible (but working!) projects in a single day. Highly recommended.


I am returning to the development world after 7 years and this has been my problem. I have to decide on what modern packages to use for everything in addition to the usual tug of get it done vs. perfectionism.

Like other large tasks, the only way I have found to get hem done sometimes is to just start on a little piece without overthinking. This can be at the beginning or in the middle of the project.


Given the hype with AI, I was seriously expecting a section of this to be taking pictures of the pork itself, and then using machine learning to figure out whether to turn the heat up or down.

So, just in case you're feeling guilty for over-engineering this, it could have been WAY worse, hahaha. This is the just-right level of overengineering.


I considered, for a very short while, trying to do some sort of OCR on the image to pull out the thermometer temperature and graph it over time. But that seemed a bit crazy. My first thought was https://xkcd.com/1425/.


You should check out Tesseract. You can do a lot with just running a cli command on your image.


That XKCD isn't accurate anymore!


I have to admit that my first thought upon reading the title was that this was some satirical piece about the way some people announce or describe their software.

"Doohickey - CLI app written in C++, Boost, and the STL"

"whatchamacallit - an admin module written in JS, React, React Saga, Storyboard, Redux, Express, nginx, Electron and markdown"

"mugabe-rails - a library written in Ruby to parse JSON"

"lasagne - a meal made using cow, spaghetti, and tomato"

Instead, what I took away from it was something much more insightful and mature. He pretty much defined his most minimal MVP, committed to getting that working, and completely dispensed with the notion that he had to invest in the more fancy tech up front. He got a working solution for his problem and if needs be, it can be made fancier now it actually works for him.


Hah, thanks! I had a tough time coming up with a title for this. The pulled pork was the star of the story, and this project wouldn't have existed without it, so I went with that in the title. I tried to come up with something more generic but it was tough.


For years I've been wanting to write something that lets me use a cheapo webcam to plot timeseries temperature data from cheap (ie. non broadcasting) thermometers and thermocouples, something like the Chris' Coffee E61 grouphead digital thermometer[1] I have attached to my espresso machine.

Like you I was also keen to automate my WSM smoker, and ended up buying a £20 Inkbird PID controller[2], hanging the thermocouple off the lid and hooking the 12v relay output directly to an old case fan attached via ducting to one of the vents. For I now get temperature stability to +/- 3 degrees C, and fuel that used to last 3 hours now lasts 11!

My 2c aside, I really enjoyed reading your writeup, and I wouldn't have stuck with it and learnt as much had your chosen subject not been so close to my heart.

[1]https://www.chriscoffee.com/e61-digital-thermometer-adapter-...

[2]https://www.amazon.co.uk/Inkbird-Temperature-Controller-Ther...


Thanks! Glad you enjoyed it. Your project sounds great, I've toyed with the idea of adding a PID/fan to this smoker somehow. The ones I had seen (from looking into adding a PID to a Rancilio Silvia) seemed awfully expensive, but hey, £20 ain't bad. I might just try this ;)

Another application I want to apply a PID to is coffee roasting, but that's a whole other kettle of fish.

EDIT: Oh wow, this one is only $16! https://www.amazon.com/Inkbird-All-Purpose-Temperature-Contr...

EDIT 2: Based on a review, it sounds like that $16 one won't measure temperatures above 210F. Bummer.


In case you haven’t already found it, ssocr may prove useful.

https://www.unix-ag.uni-kl.de/~auerswal/ssocr/


I'm a heater meter fan myself (with a combination blower damper)

https://github.com/CapnBry/HeaterMeter


This looks like an awesome level of overkill. Right up my alley. Maybe I'll build one of these next :)


Sorry, Bob. I can't make it to the BBQ event this year. My grill's CPU just died.


Meh. It's not real overkill if you don't have fail-over hardware.


Suppose we could make it triple-redundant and call it "The Raman Grill".


For vegans and other vegetarians, it is possible to prepare green jackfruit into a reasonable approximation of pulled pork. Most people use liquid smoke, but if you can use the nerdified grill process to perfectly smoke your jackfruit with actual smoke, so much the better.


Pressure cooker + liquid smoke. 9/10ths as good.

Disclaimer: I say this as a firm believer in the power of charcoal.


The recipe I followed (AmazingRibs' Perfect Pulled Pork [0]) mentions a "fast method" that involves smoking for 2 hours with lots of smoke, and finishing in the oven. I wonder if smoker + pressure cooker would be even faster and still get the benefits of the smokiness. I guess it still wouldn't have the bark but it sounds like an experiment I'll need to try.

0: https://amazingribs.com/tested-recipes/pork-chops-pulled-por...


Cool project! I've done the "low and slow" part using sous-vide then a chill bath and a quick smoke on the grill for bark. Same time-frame (probably even longer) but just a bit more convenient with the precision temperature of the sous-vide. https://www.seriouseats.com/2016/07/food-lab-complete-guide-...


fast method works fine, have done it myself on occasions when my fire went out on an overnight smoke. At 4 am its easier just to toss it into oven to finish vs getting another fire going.


Liquid smoke is critical here.


Sister does pulled pork in a pressure cooker as well. Pointless otherwise at this point. Takes no time, and comes out awesome.


Choking down the rage this comment inspires in me, let me just say that pressure cooking pork in a vat of liquid is NOT the same thing as a slow-smoked pulled pork and to call proper barbecue pointless is affront to all that is good and decent.


You could feed most people pressure cooked pulled pork with liquid smoke and they wouldn’t know the difference.

And the ones that can tell the difference, will inevitably go on to eat something else after the meal is finished.

It’s just not worth the time and effort unless you’re a hobbyist.


You don't get any bark without the real smoke.


Pulled pork is too time consuming to do properly for pretty much everybody. And with a couple of tricks to add texture and smoke you can create a very close copy with very little effort.


I have pressure-cooked dozens of pork shoulders, and I will say the only instances they've ever disappointed is when I didn't give them enough time (which in a pressure cooker just means 30-60 more minutes, not hours). give yourself time and don't be afraid to put it back in if it's not falling apart.


How does pressure affect the time needed to break down collagen? The sweet spot temp. for most BBQ cooking is 225˚F, which is already above water's boiling point at standard pressure, so I'm unclear on how increased pressure would benefit cook time.


Collagen breakdown is a kinetic process(that is, a function of temperature * time). So you can decrease the time if you increase the temperature, that gets you part of the way there. But then there is also the fact that in a BBQ smoker, you are getting almost 100% of your heat on meat from air convection, whereas in a pressure cooker your food is either submerged in liquid, or in a high pressure steam, meaning that the heat transfer is much, much higher in a pressure cooker(this is the same concept why exposing skin to 40 degree air is much more pleasant than dunking that same skin in 40 degree water).

I haven't cooked pulled pork in a while, but I have been making some pulled chicken in my pressure cooker every now and then the past few months. After 15 minutes on high pressure(~15 psi, 250 degrees), the chicken is fully cooked and literally falling apart as I pick it up under its own weight, which is something I never get even when I smoke chicken in my digitally controlled electric BBQ.

On a side note, I can get boneless skinless chicken thighs for $1.50/lbs, and cook up a big pile of delicious meat in 30 mins that lasts a week. Highly recommended for the cheap, lazy, or people who just like pulled chicken.


That's the temperature outside the meat. The meat itself is kept cool by evaporation.

Pressure cooking lets the internal temperature rise faster by suppressing the boiling on the surface.


slaps forehead

Of course! It would totally demolish "the stall". I have a pellet grill, and I'd love it if it had a high pressure mode that would kick in, sealing off the vents, once the internal temp's rate of change slowed to a certain point.


What you need to break down collagen to gelatin is just energy. Energy = heat * time, so you can break it down in less time by using higher heat differential (higher temperature), which is exactly what a pressure cooker does.

I have a stew that would normally take 3 hours simmering on the stove that can be done in 20 minutes in a pressure cooker.


Except you don't want to do that in BBQ because it can toughen, dry out/over-moisten, or burn the meat in some combination. I know the pressure cooker is better than the dry air convection of a smoker to some degree, but if it were that simple, then people would just crank up temps and use a large internal water pan.


Agreed, I was only addressing the part about collagen breakdown. Pressure cooking makes most sense when you don't change the medium of cooking, as you say, boiling bbq doesn't make much sense. Otherwise the principal is the same, apply pressure to prevent water from turning to vapor. When boiling a stew, this lets water reach higher temperatures without evaporating (breaks down collagen faster), in air convection it prevents moisture from evaporating and cooling/drying the food.


Interesting. That sounds way faster and easier, I'll have to give that a try.


no bark though right?


Not out of the pressure cooker, but after I shred the meat, I lay it flat on a baking sheet. pour some of the remaining juices over it, and then broil it in the oven for about 2 minutes. It gives you a nice pseudo bark.


this is also my preferred way of making carnitas (but leaving the pork in chunks rather than shredding)


Neat project, but thanks for making me hungry in the afternoon :P

+1 for OP's thermometer manufacturer Thermoworks, I'm a happy customer as well (and unaffiliated).

As an aside, if you're in the market for an electronic temperature measurement device, they're currently running a Father's Day Sale. (https://www.thermoworks.com/)


Thermoworks is great. I think my first experience with them was their Thermapen product. It's awesome for checking internal temperatures damn near instantly.


Dave, you should get a Weber Smoky Mountain instead of a Kettle and then you won't need React Native. :-)

Nice article, thanks for sharing!


I couldn't tell if Pulled Pork referred to actual pulled pork or, as I assumed, to some new framework.


I was really, really relieved that it was, in fact, pulled pork.

There are only so many namespace collisions I can deal with; that isn't one of them.


Neat, I'm a huge fan of anything in the intersection of programming and bbq.


Besides a thermometer that can be read remotely, if you've got the money, a pellet smoker seems like the way to go: the heat and smoke come from actual wood being burned, but you can set the temperature and let it keep it there.


I have one. I like it a lot. I don't think they can hit quite the quality as a manual charcoal / wood vertical smoker except possibly at brands the higher end (above $2000, mine cost about 1/4 of that), especially if you like a deep rich smoke flavor, but for the convenience you get for the ease of use if you don't have the time to hone your pit skills (not to say a pellet grill doesn't have its own learning curve), I think it's worth the trade-off. Also, they are electro-mechanical devices kept in the outdoors and prone to the malfunction that you'd expect if not carefully maintained. Good companies have strong warranties, but some don't.


Yeah but what's the fun in that?


Nice.

Though I have to say, my favorite pulled pork hack involves C, PHP, an Arduino, a Pi, a couple of thermocouples, and a fan controlled by a solid state relay[1].

[1] https://github.com/CapnBry/HeaterMeter/wiki

Yours is simpler, and the photo part is really nice. But the fan control on the heatermeter project adds a whole other dimension.


When all you've got is a hammer...


Really just wanted to learn how to use the hammer, in this case. But still, yeah... you're not wrong ;)


I was really looking forward to the part where you used servos to open and close the vents with a PID algorithm. Maybe v2 :)


Thought about it...

I've seen some people using a fan that they modulate with a PID to control the temp, which is on my list of "someday maybe" projects, heh. I wanna say there's even an existing product that does this, but I forget the name.


Open source Go one called QPID on the Raspberry Pi, https://github.com/bbqgophers/qpid

Fairly easy to glue together sensors to roll your own, I made an egg incubator with basically the same pieces that had a webcam too, http://www.velvetcache.org/2018/03/04/chicken-cam-incubator-...

I like the reuse of the phone though, I wonder if there is some sort of bluetooth board out there that can bridge the phone to the gpio stuff.


Flame Boss and CyberQ/PartyQ/DigiQ


And PitmasterIQ


As long as this pulled pork doesn't include the use of Mustard I can approve this.


No mustard. Sprayed with water before applying the rub. Added BBQ sauce sparingly to the final result.

I must admit though, that I forgot to apply the rub before I put it on the smoker! (7am me was groggy, and rushing) So I applied it about 30 minutes into the cook. Surely not optimal, but it came out delicious anyway so hey, whatever :)


I've done very similar actions at 5 and 6am :D

I would recommend rubbing with oil before the rub, and not water. Most seasonings are oil-soluble and will work better if you've oiled them first.


Vinegar is by far the best pulled pork preparation!


(Bottled mustard is mostly vinegar.)


Not really. It is true that many mustards utilize vinegar to slow the decomposition of the mustard, but it's not really the primary ingredient (perhaps by weight in some cases, but not culinarily). And being bottled has nothing to do with whether vinegar is used or not. But most importantly (and this should be obvious), it's not anything like a replacement for vinegar.


Why would such a simple app crash?


>Or: Taking a Picture Every 30 Seconds and Sending It To A Server.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: