229 karma · joined October 9, 2015
I would remind everyone at family gatherings that I was collecting them if they didn’t need them and quickly had about 15 I could use.
This style of application development benefits from an object-oriented language. Where an object encapsulates the domain logic of business rules. This can be accomplished in Go with structs and funcs.
Classes in Java make good domain models because of (overbearing) enforcement of file structure (object creation validation rules in the constructor, limit access to properties to getter/setter methods that can verify inputs before mutation, yadda yadda). In domain models, neatness and organization counts a lot for the long-term health of the code.
My opinion is that Go is well suited to the task of creating autonomous worker applications that enforce business logic rules for domain objects with well-defined borders. If your domain objects have overlapping concerns or you have actors/business rules that need access to more than one domain object for calculation/mutation you would be wise to think carefully about the application structure before selecting Go as your language.
While a sleek looking use case on the surface, mounting the PI as a fake, non-standards compliant, mass storage device is just a hack.
For example the first recipe will not work as expected with out a multi-column unique index (specifically the MySql example).
I feel that the preexisting knowledge required for such examples does not align with the stated target audience for the book.
Also ‘find’ing and ‘filter’ing arrays is more error prone (like not properly handling a miss on a find).
I don’t completely agree with the author, but the idea that more care needs taken when dealing with arrays is worth considering.
Arrays will always have important uses. Tuples, enumerations, and the like. However, ‘n’ database records shoved into an array and then iterated over in a for-loop is a cumbersome way to structure a program.
That’s my take on it.
I’ve both used strategies on many different projects. Regardless of the development strategy I’ve seen nasty merge parties. The way to avoid those merges is to reduce your batch size and keep your un-integrated changes to a narrow scope.
If you need to make changes out side of that scope. Stash your work; create a new branch; make the change; let your teammates know what you did; before going back to your other branch. You can then integrate that fix back to your local copy. But the important thing is that your team mates can also sync that one off change to their local copy too.
The worse thing is when two developers find the same bug and fix it simultaneously in different commits. Trunk-based and GitFlow both have this problem. Stick to the scope of work that was coordinated in your standup meeting for the day and let your coworkers know if you need to go outside of that scope. Be conscientious.
(Complete aside: Try to do trunk based development in a Perforce code base and you will learn a lot about reducing your the batch size of your commits and communicating the scope of code changes. Perforce requires you to be team oriented when developing)
The dough hook, whisk, and other attachments secure in place with machined fittings so there is no play or wiggle. This has made them last.
I took the top off of it 10 years ago to make sure it was still properly lubricated. That’s all the maintenance it has ever had. (Well I broke one of the Pyrex mixing bowls…but eBay)
There are many Americans in the Appalachian area of the United States that care more about where their power comes from than where their food comes from or contains. People in other parts of the world may have different priorities. But most households in West Virginia not only know what type of power is used to run their homes but know the name of the coal mine that it was dug out of.
The topic of deforestation is only whispered in at the end, almost a footnote. However, burning the Amazon for farmland to produce beef in Brazil should be part of the headline.
My user story is: I’m a hobbyist user that likes to record game matches for personal review (analysis of my strategy/mistakes for self improvement). I know that OBS is much more powerful that what I need. However, the design of the software allows me to focus on features I need without the distractions of the features I’m not concerned with. I’m able to complete the tasks I need from the software with amazing ease.
It really allows me to enjoy the games I’m playing so much more.
It was our instructor’s way of teaching us to collaborate and forcing us to use Clear Case on a daily basis.
I’m definitely going to keep up with this project. If only for nostalgia.
This reminds me of why GitHub should create it’s own App Store (yup, I’m gonna beat this drum):
I can navigate the source ask questions about parts that make me suspicious, and then install a prebuilt binary with confidence that the binary was the sum of what I reviewed.
I would have ignored the post and not commented except that the referenced R. Martin article is the same style of immediate reference invocation diatribe and they both suffer from the same short comings. Turtles all the way down.
Alas, this comment is more of the same, shame on me. Please learn from our mistakes.