Podcasts about existing code

This week Carter and Nathan read Donella Meadows' Thinking in Systems. A foundational primer on systems thinking, the book explores how stocks, flows, feedback loops, and leverage points shape everything from ecosystems to organizations. Join them as they discuss how systems thinking applies to software engineering, the hidden structures behind burnout and tech debt, and how to make high-leverage changes in complex systems.-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Thinking in Systems by Donella H. Meadows https://amzn.to/4cMB35k (paid link)Tidy First?: A Personal Exercise in Empirical Software Design by Kent Beck https://amzn.to/3RoB9pR (paid link)Refactoring: Improving the Design of Existing Code by Martin Fowlerhttps://amzn.to/43Wqk5Q (paid link)Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neal Fordhttps://amzn.to/3Y7CNjk (paid link)One Nation Under Blackmail, Vol. 1: The Sordid Union Between Intelligence and Crime that Gave Rise to Jeffrey Epstein by Whitney Alyse Webbhttps://amzn.to/3RsMt4f (paid link)Slow Productivity: The Lost Art of Accomplishment Without Burnout by Cal Newporthttps://amzn.to/3EH8MAe (paid link)The Software Engineer's Guidebook: Navigating Senior, Tech Lead, and Staff Engineer Positions at Tech Companies and Startups by Gergely Oroszhttps://amzn.to/3ExwPSa (paid link)What Is ChatGPT Doing ... and Why Does It Work? by Stephen Wolfram https://amzn.to/4iuSUim (paid link)----------------00:00 Intro 01:41 About the Book03:43 Thoughts on the Book08:07 Covering the Foundations and Defining Terms16:36 Feedback loops22:31 Overconfidence and why models lead us astray.35:56 Paradigms and Framing49:30 Leverage Points01:02:04 Final Thoughts----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

In this episode of Book Overflow, Carter and Nathan discuss Tidy First? by Kent Beck. Join them as they discuss when you should prioritize tidying your code over feature improvements, what tidying means, and the Beck's thoughts on software and the time value of money! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- Tidy First?: A Personal Exercise in Empirical Software Design by Kent Beck https://amzn.to/40uOEtL (paid link) Refactoring: Improving the Design of Existing Code (2nd Edition) by Martin Fowler https://amzn.to/3C9d5mq (paid link) Building Evolutionary Architectures: Automated Software Governance by Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage https://amzn.to/4fmoIVC (paid link) A Philosophy of Software Design, 2nd Edition by John Ousterhout https://amzn.to/4ecmYgv (paid link) The Practice of Programming by Brian Kernighan, Rob Pike https://amzn.to/4fuMP4b (paid link) ---------------- 00:00 Intro 03:14 About the Book 05:41 Thoughts on the Book 11:17 Techniques and Approaches for Tidying (Part 1) 36:20 How to prioritize and manage tidying tasks (Part 2) 47:30 Optionality, Reversibility and The Philosophy of Tidying (Part 3) 01:05:38 Final Thoughts ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

In this special episode of Book Overflow, Martin Fowler joins Carter and Nathan to discuss his book Refactoring: Improving the Design of Existing Code. Join them as Martin shares why he wrote Refactoring, how the art of refactoring has changed, and how he views the book's legacy!https://martinfowler.com/-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Refactoring: Improving the Design of Existing Code by Martin Fowler and Kent Beckhttps://amzn.to/4enmuox (paid link)The Art of Agile Development, 2nd Edition by James Shore and Shane Wardenhttps://amzn.to/47TiM3D (paid link)Make No Law: The Sullivan Case and the First Amendment by Anthony Lewishttps://amzn.to/3zJ3K3O (paid link)----------------00:00 Intro01:58 Motivation for writing the book09:45 Refactoring, Extreme Programming, and testing19:17 Estimating, Unknowns, and Complexity23:40 Trust and High Performing Teams30:32 refactoring in the wild: imitate, assimilate, innovate, best practices and sensible defaults43:39 Legacy of the book and rational for second edition47:35 What are the role of books now? Evergreen content, Long-form content in a world of short-form content.01:03:21 Book Recommendations01:09:12 Closing Thoughts----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

Carter Morgan and Nathan Toups discuss "Refactoring: Improving the Design of Existing Code" by Martin Fowler. Join them as they talk about the importance of automated testing when refactoring, how to play nice, and how refactoring can be justified as a business consideration!

I describe how the Gal Oya irrigation system got better. It's an example that might inspire hope. I also imagine how a software codebase and its team might have a similar improvement.As with earlier episodes, I'm leaning on Elinor Ostrom's 1990 book, Governing the Commons: The Evolution of Institutions for Collective Action, and Erik Nordman's 2021 book, The Uncommon Knowledge of Elinor Ostrom: Essential Lessons for Collective Action. I also mention James C. Scott's Seeing Like a State, which I discuss starting with episode 17.More about Gal Oya and similar projectsUphoff, N.T. "People's Participation in Water Management: Gal Oya, Sri Lanka". In Public Participation in Development Planning and Management: Cases from Africa and Asia, ed. J.C. Garcia-Samor, 1985Perera, J. "The Gal Oya Farmer Organization Programme: A Learning Process?" In Participatory Management in Sri Lanka's Irrigation Schemes, 1986.Korten, D. "Community Organization and Rural Development:  a Learning Process Approach", Public Administration on Review 40, 1980 (Philippines, Bangladesh)Korten, F. "Building National Capacity to Develop Water Users' Associations: Experience from the Philippines, World Bank working paper 528, 1982Rahman, A. "Some Dimensions of People's Participation in the Bloomni Sena Movement", United Nations Research Institute for Social Development, 1981 (Nepal)Rabibhadena, A. The Transformation of Tambon Yokkrabat, Changwat Samut Sakorn, Thammasat University, 1980 (Thailand). Refactoring books I have likedMartin Fowler, Refactoring: Improving the Design of Existing Code, 1999William C. Wake, Refactoring Workbook, 2003Joshua Kerievsky, Refactoring to Patterns, 2004Scott W. Ambler and Pramod J. Sadalage, Refactoring Databases: Evolutionary Database Design, 2006The Strangler Fig patternFowler's original blog postA case study I commissioned, way back when. Credits "Agriculture in Extreme Environments - Irrigation channel for wheat fields and date palms" by Richard Allaway is licensed under CC BY 2.0.

In this episode of the Laravel India Podcast, we're joined by guest Taylor Otwell Taylor discusses the how he created Laravel, how he writes documentations and why it is useful to read books He also shares some insights of how he started with programming and  the laravel ecosystem products he created. Additionally, he shares his daily routing, and how to maintain it. Overall, a great episode for anyone interested in learning more about Laravel and its ecosystem! Follow Taylor Otwell at twitter - Click Here Recommended books by Taylor Otwell - (https://amzn.to/3YxGddw) Refactoring: Improving the Design of Existing Code - (https://amzn.to/3XsHDEv) Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application - (https://amzn.to/3K84NNK) The Elements of Style by William StrunkBook by William Strunk Jr.

This last episode of ByteSized RSE before the end of 2022 is about testing your Python code.Testing is an essential part of software development, and a lot of what we cover in this episode applies to any programming and scripting language. For Python, the two big frameworks being used are unittest and PyTest. Unittest is built into Python, whereas PyTest is a module you would need to install extra.https://docs.python.org/3/library/unittest.html the built in unit testing framework of Pythonhttps://docs.python.org/3/library/unittest.mock.html mock testing in the unittest frameworkhttps://docs.python.org/3/library/unittest.html#class-and-module-fixtures fixtures for classes and moduleshttps://docs.pytest.org/en/7.2.x/ the popular PyTest frameworkMocking can be done with monkeypatch in PyTest https://docs.pytest.org/en/7.1.x/how-to/monkeypatch.html#Fixtures in PyTest: https://docs.pytest.org/en/7.2.x/reference/fixtures.html Books mentionedWorking effectively with legacy code, Michael Feathers, ISBN: 9780131177055, Pearson's, 2004Refactoring: Improving the Design of Existing Code, Martin Fowler, ISBN: 9780134757681, 2nd edition, Addison-Wesley ProfessionalByte-sized RSE is presented in collaboration with the UNIVERSE-HPC project.https://www.imperial.ac.uk/computational-methods/rse/events/byte-sized-rse/ ByteSized RSE link to Imperial CollegeSupport the Show.Thank you for listening and your ongoing support. It means the world to us! Support the show on Patreon https://www.patreon.com/codeforthought Get in touch: Email mailto:code4thought@proton.me UK RSE Slack (ukrse.slack.com): @code4thought or @piddie US RSE Slack (usrse.slack.com): @Peter Schmidt Mastadon: https://fosstodon.org/@code4thought or @code4thought@fosstodon.org LinkedIn: https://www.linkedin.com/in/pweschmidt/ (personal Profile)LinkedIn: https://www.linkedin.com/company/codeforthought/ (Code for Thought Profile) This podcast is licensed under the Creative Commons Licence: https://creativecommons.org/licenses/by-sa/4.0/

Let's be honest. We've all copied and pasted code from the internet. There are many great code sources and in this episode, Ben and Michael discuss how to leverage existing code. They explain how to understand a code base and some best practices for contribution.  Sponsors Chuck's Resume Template Developer Book Club starting with Clean Architecture by Robert C. Martin Become a Top 1% Dev with a Top End Devs Membership

The probe by the Malaysian Anti-Corruption Commission (MACC) into senior judge Datuk Mohd Nazlan Mohd Ghazali has triggered outcry from legal experts who view this move could undermine the independence of the judiciary. We speak to SUHAKAM Commissioner Dato' Mah Weng Kwai about the processes in place to sanction judges and lawyers for ethics breaches. Image Credit: Arnain/Shutterstock.com

Consejos para evitar uno de los problemas fundamentales de TDD. Intenta no caer en esta trampa!TDD is dead. Long live testing by David Heinemeier Hansson (creator of Ruby on Rails): https://dhh.dk/2014/tdd-is-dead-long-live-testing.htmlRIP TDD by Kent Beck (Author of "Extremme Programming Explained" and "inventor" of TDD): https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847Is TDD dead? by Martin Fowler (Famous by "Refactoring: Improving the Design of Existing Code" but many others contributions): https://martinfowler.com/articles/is-tdd-dead/Building features with Spike & Stabilise: https://medium.com/ingeniouslysimple/building-features-with-spike-stabilise-1906a9006a87What is programmer anarchy and does it have a future?: https://martinjeeblog.com/2012/11/20/What is Lean Software Development: https://www.productplan.com/glossary/lean-software-development/Extremme Programming Explained (Kent Beck): https://www.amazon.es/Extreme-Programming-Explained-Embrace-Embracing/dp/0321278658/ref=sr_1_1?__mk_es_ES=ÅMÅŽÕÑ&crid=1OGSUTQ998TZ0&dchild=1&keywords=extreme+programming+explained&qid=1615537489&sprefix=extreme+program%2Caps%2C179&sr=8-1Test Driven Development: By Example (Kent Beck): https://www.amazon.es/Driven-Development-Example-Addison-Wesley-Signature/dp/0321146530/ref=sr_1_1?__mk_es_ES=ÅMÅŽÕÑ&dchild=1&keywords=tdd+by+example&qid=1615536016&sr=8-1Refactoring: Improving the Design of Existing Code by Martin Fowler: https://www.amazon.es/Refactoring-Improving-Existing-Addison-wesley-Signature/dp/0134757599/ref=sr_1_4?__mk_es_ES=ÅMÅŽÕÑ&dchild=1&keywords=Refactoring+to+Patterns&qid=1615540711&sr=8-4Refactoring to patterns by  Kerievsky Joshua: https://www.amazon.es/Refactoring-Patterns-Addison-Wesley-Signature-Fowler-ebook/dp/B001TKD4RQ/ref=sr_1_1?__mk_es_ES=ÅMÅŽÕÑ&dchild=1&keywords=Refactoring+to+Patterns%3A+Kerievsky%2C+Joshua&qid=1615540653&sr=8-1mail: info@joantolos.comSwag: http://store.joantolos.comOfficial web: http://www.joantolos.comApple podcast: https://podcasts.apple.com/es/podcast/nada-nuevo-bajo-el-sol/id1563220961Spotify: https://open.spotify.com/show/6BcHhm3wO3cvSIMZL6ssG8

So the last question in this email has to do with how do you know why where to start testing because you're adding testing to an existing project and so most of your tests are actually writing tests for code that exists and so it's not like there's no test driven development there or anything like that. And so, how do you know like how far do I go and testing when when can I stop and say that this component is tested? Does it have to do with code coverage or whatever? And my answer to that is I actually do have a blog post how to get started with testing or how to add tests to an existing code base. Where I talk about with just kind of in general you want to start with a single end-to-end test and you add some static testing and then you add the tooling for and unit integration and then just add over time and you can go take a look at that for a little bit deeper read on that, but if we're talking specifically about I have this component and I want to add tests to it where do I start and for me it comes down to thinking about use cases more than thinking about code coverage. And I actually have a blog post ofAbout that as well. But basically the idea is I don't really care about code coverage. Lines of code is basically irrelevant. All that the the code coverage report tells me is the use cases that I'm not covering. That's what I'm thinking about when I'm looking at the code coverage report. So if there's like an if statement that is not covered then that just says, oh, okay, so whatever use case that code exists for that's a use case that I'm not testing for because use cases are all that we care about. We care about this.Code working for the users whether that be developer users who are calling our functions or rendering our components or end users who are clicking the buttons were rendering whatever. And so you want to think about the use cases that you're covering and then you weigh them relative to the confidence that you need for other use cases of other components as well as the features that you need to build and bugs you need to fix and things like that. So it really comes down to what we said before about weighing the return on your investment of time for writing.Versus features that you can work on Now let's say that you live in a world where it doesn't matter You don't need to work on features you can just totally focus on tests. There is a stopping point for sure and the stopping point is when you feel like you've covered all the use cases. Now for like open source libraries and stuff it typically end up covering all of the use cases you get a hundred percent code coverage, but for applications. I never find myself in a situation where I can just spend a ton of time on tests. I need to work on features and that's where you just need to kind of weigh, what are the things that I am going to write test for.Versus new features or whatever. Hope that helps Ciao.

In this episode, we talked to Russell about his team’s CI journey, from the struggles of hosting an on-premise Jenkins solution to building a cutting-edge case of mobile infrastructure on Bitrise. We explored how their responsibilities have shifted from the team to the platform: whether it’s a beta build or delivering to the app stores, the team now has the entire process of building, testing, code signing, and shipping automated. We also discussed how the switch has impacted their day-to-day job, their team structure, and how it resulted in an increase in agility and productivity. You can find out more about Russell and his projects here, or check out their Engineering and AI blog. If you're interested in joining Compass, head to their careers page and explore their open positions. Books and resources referenced in this episode: Clean Code: A Handbook of Agile Software Craftsmanship, by Robert C Martin Refactoring — Improving the Design of Existing Code, by Martin Fowler, with Kent Beck Treehouse: Online courses for people of all skill levels and backgrounds How to UI test Push Notifications and universal links in the iOS simulator Code References: https://github.com/UrbanCompass/Mussel https://github.com/UrbanCompass/snail Open Source Tools: https://github.com/leejarvis/slop https://github.com/CocoaPods/Rome https://github.com/tmspzz/Rome https://github.com/Carthage/Carthage https://cocoapods.org/ https://github.com/tuist/tuist https://docs.ruby-lang.org/en/2.3.0/ERB.html

La natura stessa del lavoro di uno sviluppatore comporta la necessità di un continuo miglioramento e una continua crescita personale. Oggi vi parlo dei miei piani per il 2021 e del percorso che ho iniziato, che sento di poter consigliare a chiunque voglia crescere come sviluppatore.I libri che ho citato: - Agile Technical Practice Distilled (https://amzn.to/3o9dadg)- Extreme Programming explained (https://amzn.to/3c7Kejh)- Test Driven Development: by example (https://amzn.to/398rAFY)- Refactoring: Improving the Design of Existing Code (https://amzn.to/3sO7kBt)- Growing Object-Oriented Software, Guided by Tests (https://amzn.to/2KFjnzT)- Working Effectively with Legacy Code (https://amzn.to/2Y35nD9)- Design Patterns: Elements of Reusable Object-Oriented Software (https://amzn.to/39alDZg)- Practical Guide to Structured Systems Design (https://amzn.to/3odL802)- Clean Code: A Handbook of Agile Software Craftsmanship (https://amzn.to/3iDZFkH)- The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (https://amzn.to/3qOVVzD)______________________________________________________________________Per altri contenuti a tema programmazione e pratiche Agili, seguimi anche su Youtube: https://www.youtube.com/channel/UCow5aybmZhzR7HbPf8JmcmA .Il mio sito personale: https://www.dan-the-dev.it Il mio profilo LinkedIn: http://linkedin.com/in/daniele-scillia/ Il mio profilo Twitter: https://twitter.com/danielescillia (su Twitter potete commentare il podcast nel tweet dedicato all'episodio!)Il mio profilo GitHub: https://github.com/dan-the-dev/Per contattarmi: daniele.scillia@gmail.com (sono disponibile per collaborazioni, progetti, eventi, conferenze, corsi, coaching, mentoring).

Materiały dodatkowe:Refactoring: Improving the Design of Existing Code,Martin Fowler, with Kent Beck , klasyka gatunkuWorking Effectively with Legacy Code, Michael Feathers, druga klasyka warta przeczytania i posiadania w swojej biblioteczceFearless Refactoring: Rails Controllers, Andrzej Krzywda, wspomniana przez Andrzeja jego książka o refaktoryzacji Railsowych kontrolerówKatalog przekształceń refaktoryzacyjnych Martina FowleraTrunkBasedDevelopment.com, skarbnica wiedzy jeśli chodzi o podejście Trunk Based. Można tu znaleźć zarówno przypadki użycia tej techniki, jak i przydatne wzorce, rozwiązujące typowe problemyNasze profile na Instagramie:Profil Andrzeja KrzywdyProfil Mariusza GilaPrzy okazji wizyty Andrzeja w studio nagraliśmy coś jeszcze! Zapraszam do śledzenia mojego kanału na YouTube.

Robby speaks with Clare Sudbery, Lead Engineer with Made Tech. They discuss how to document and prioritize technical debt with a visual tool, trunk-based development patterns, and the importance of getting fast feedback.Helpful LinksFollow Clare on TwitterIn Simple TermsClare's upcoming workshops and speaking engagementsMadeTechClare on MediumRefactoring: Improving the Design of Existing Code (2nd Edition) by Martin FowlerDelusions of Gender: How Our Minds, Society, and Neurosexism Create Difference by Cordelia FineSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

Nesse episódio só sobre Clean Code, os hosts conversam sobre como escrever código legível e escalável, e dão dicas para quem quer se iniciar no assunto. Siga a gente no Twitter: twitter.com/BuildFailedCast Links mencionados no episódio: - Clean Code: A Handbook of Agile Software Craftsmanship: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 - Refactoring: Improving the Design of Existing Code: https://www.amazon.com.br/Refactoring-Improving-Existing-Addison-Wesley-Signature-ebook/dp/B07LCM8RG2 - API Design Guidelines: https://swift.org/documentation/api-design-guidelines/ - Melhorando o tratamento de erros do seu App - Lucas Santos - 34º CocoaHeads Campinas @ Zup: https://www.youtube.com/watch?v=SSvdm5X36Rk

This week's episode features Liz Keogh, Lean & Agile Coach and Trainer. Robby and Liz talk about behavior-driven development (BDD), what it's like to be a coach, and more! Helpful Links: Follow Liz on Twitter Visit Liz's website The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford Refactoring: Improving the Design of Existing Code by Martin Fowler Subscribe to Maintainable on: Apple Podcasts Overcast Or search "Maintainable" wherever you stream your podcasts. Loving Maintainable? Leave a rating and review on Apple Podcasts to help grow our reach. Brought to you by the team at Planet Argon.

On this week's episode, Robby talks to Colin Jones, CTO at 8th Light. They chat about software consultancy, what it means to be a good guest in someone else's codebase, and more. Helpful Links: Follow Colin on Twitter Follow 8th Light on Twitter Connect with Colin on LinkedIn Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann Refactoring: Improving the Design of Existing Code by Martin Fowler Subscribe to Maintainable on: Apple Podcasts Overcast Or search "Maintainable" wherever you stream your podcasts. Loving Maintainable? Leave a rating and review on Apple Podcasts to help grow our reach. Brought to you by the team at Planet Argon.

Panel Joe Eames Luis Hernandez Mike Dane Sam Julien Joined by special guest: Tommy Williams Episode Summary In this episode of the Dev Ed podcast, the panel is joined by special guest Tommy Williams, who is currently a Software Manager at Playware Media, and has a strong background in web development. He starts off the discussion by explaining what the term performance tuning really means, and the other panelists join in with their own definitions and give examples to elaborate on it. They talk at length about the tradeoff between performance tuning and maintainability while each sharing their valuable experiences. They then steer the discussion towards learning performance tuning, what resources and tools to use, recommend some good courses to listeners and discuss how to go about learning it in general. Tommy talks about the performance issues that can possibly come up while writing web applications and ways to practice performance tuning followed by the panelists’s tips on it as well. They conclude the show with picks. Links jsPerf Chrome DevTools Lighthouse Modern DevTools Umar Hansa Tommy’s LinkedIn Picks Mike Dane: Saint Thomas Luis Hernandez: Refactoring: Improving the Design of Existing Code Sam Julien: Keyboard Maestro Joe Eames: Zombicide Tommy Williams: Dominican slang word -Vaina

Panel Joe Eames Luis Hernandez Mike Dane Sam Julien Joined by special guest: Tommy Williams Episode Summary In this episode of the Dev Ed podcast, the panel is joined by special guest Tommy Williams, who is currently a Software Manager at Playware Media, and has a strong background in web development. He starts off the discussion by explaining what the term performance tuning really means, and the other panelists join in with their own definitions and give examples to elaborate on it. They talk at length about the tradeoff between performance tuning and maintainability while each sharing their valuable experiences. They then steer the discussion towards learning performance tuning, what resources and tools to use, recommend some good courses to listeners and discuss how to go about learning it in general. Tommy talks about the performance issues that can possibly come up while writing web applications and ways to practice performance tuning followed by the panelists’s tips on it as well. They conclude the show with picks. Links jsPerf Chrome DevTools Lighthouse Modern DevTools Umar Hansa Tommy’s LinkedIn Picks Mike Dane: Saint Thomas Luis Hernandez: Refactoring: Improving the Design of Existing Code Sam Julien: Keyboard Maestro Joe Eames: Zombicide Tommy Williams: Dominican slang word -Vaina

When I was in my early 20s and someone told me to prioritize freedom and flexibility, I’d cringe and think, “Yes but how?”   Over the past fifteen years, I’ve asked this question to people I’ve met. Through trial and error, I’ve learned to incorporate or tweak parts of their how to fit my needs. As a result, I’ve learned there is more than one how, and to be wary of those who claim there is only one!   One approach we explored earlier this year was building a Company of One. Paul Jarvis and I explored how he went from being a freelancer and providing a service to scaling his business to create products. In the Build episode, we shared some of the common themes. If you missed the episode, you can check it out here.   This month, I want to rewind and explore the first part, becoming a freelancer.   Becoming a freelancer is one approach to gaining more freedom and flexibility. And while it’s easy to glamorize being your own boss, it can take time (many years) to get a business off the ground.   You have to figure out how to market yourself, manage clients, price your service, and still have enough hours left in the day to do the work!   All of these tasks can leave you feeling overwhelmed. To help you think about the transition, gain some perspective, and most importantly, work through the overwhelm, I’ve invited Gregg Goldner, who is a freelance developer and President of Two Sun Traders, LLC to share his experience.   Whether you are a freelancer, want to be one, or are just curious, I’d highly recommend tuning into this week’s episode to learn the following from Gregg:   Why Gregg wanted more flexibility in his life and chose to transition from being a music teacher to a software developer How he made the transition to becoming a software developer The skills he learned from having been a school teacher and how they applied to software The experience that led Gregg to choose to be freelancer instead of a startup founder How he initially priced himself, then changed his pricing over time The importance of honing your craft How he interviews clients and picks projects   I loved this quote from Gregg because it showcases how you need to focus as a freelancer:   “Putting on every single hat and then realizing I don’t like half those hats. Wouldn’t it be great if I didn’t have to do those things? What are my strengths and weaknesses, and how can I find people who have different strengths and weaknesses?” — Gregg Goldner, President of Two Sun Traders, LLC   In the episode, Gregg mentions a number of resources, here are links to them:   The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering by Frederick P. Brooks Jr. Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin Refactoring: Improving the Design of Existing Code by Martin Fowler Code Complete by Steve McConnell iOS Development Tutorials by Ray Wenderlich A weekly video series on Swift programming A hands-on guide to learning Swift Subscription learning platforms Packt and Lynda.com   If you’ve been following Build for a while, you may recall I did an episode with Jessica Hische who is a letter, illustrator, and type designer a few years ago on a similar topic: How To Prepare To Strike Out On Your Own And Pursue Your Creative Calling. Listen to the episode here. I always find it helpful to revisit a topic and compare notes, plus some people’s voice resonates more than others, so I’d highly recommend you check out that episode too! -- Build is produced by Femgineer. 

GuestTwitterYoutubeLinkedInWebsiteWeb Design - Start Here: A No-Nonsense, Jargon Free Guide to the Fundamentals of Web Design by Stefan MischookCoursesInteractive Web DeveloperBeginner PythonComplete FreelancerComplete EntrepreneurStudio WebWebsiteResources Mentioned during the episodeRefactoring: Improving the Design of Existing Code by Martin FowlerShogun: The First Novel of the Asian saga by James ClavellThe Hobbit and the Lord of the Rings by J.R.R. Tolkien See acast.com/privacy for privacy and opt-out information.

Это последняя запись в уходящем году. Мы собрались большим звездным составом. Некоторые из гостей коллеги по цеху - ведущие других подкастов, так что в какой-то момент вы можете забыть что это RadioJS :) В этом выпуске принимали участие: * Александр Майоров (ведущий Radio.JS, помогает найти работу мечты) * Сергей Рубанов (соведущий Radio.JS, организатор Beer.JS Moscow) * Павел Малышев (евангелист Svelte) * Петр Мязин (ведущий подкастов 5minreact, 5minphp) * Женя Фомин (Moscow Vue.js meetup organizator) * Андрей Мелихов (ведущий подкастов "Ночной фронтенд" и "Девшахта") Cсылки про то, о чем говорили в выпуске: * Framework Svelte (https://svelte.technology/) * Telegram канал по Svelte https://t.me/sveltejs * Svelte: обзор и сравнение – Александр Федотов (https://www.youtube.com/watch?v=tgvgCAOR4O8) * Легенда о Фреймворке Всевластия (https://habr.com/post/420113/) * babel-plugin-rawact (https://github.com/sokra/rawact) * Beta сайта TC39 https://tc39.github.io/beta/ * Node.js Design Patterns - Second Edition: Master best practices to build modular and scalable server-side web applications (https://www.amazon.com/dp/1785885588/ref=sspa_dk_detail_0?psc=1) * Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler)) (https://www.amazon.com/gp/product/0134757599?ie=UTF8&tag=martinfowlerc-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0134757599) * Public and private class fields (https://developers.google.com/web/updates/2018/12/class-fields) * https://github.com/Eloston/ungoogled-chromium * https://twitter.com/BrendanEich/status/1071851836955598850 * https://twitter.com/BrendanEich/status/1071863601097523200

Refactoring: Improving the Design of Existing Code : https://www.amazon.fr/Refactoring-Improving-Design-Existing-Code/dp/0134757599/ref=sr_1_2?ie=UTF8&tag=benoitgantaum-21 Working Effectively with Legacy Code : https://www.amazon.fr/FEATHERS-WORK-EFFECT-LEG-CODE/dp/0131177052/ref=sr_1_2?s=english-books&ie=UTF8&tag=benoitgantaum-21 Artisan Développeur - Niveau 3 : https://maison.artisandeveloppeur.fr/dompter-les-dependances?coupon=LANCEMENT

Support these videos: http://pgbovine.net/support.htmhttp://pgbovine.net/PG-Vlog-238-prototyping-with-code-2.htmRecorded: 2018-11-23

What is the easiest way to make an existing functions more functional? It’s quite a simple technique and you can apply it today.

Muy buenas a todos! Estoy muy contento de retomar Game Stuff, el podcast donde entrevisto a profesionales del sector de los videojuegos. Para el episodio número 5 tengo el placer de contar con la presencia de Pablo Domingo, Agile Coach y Scrum Master de King. Pablo es un profesional con una carrera de más de 13 años en el mundo de las metodologías ágiles, en la entrevista de hoy vamos a tener la oportunidad de conocer de primera mano cómo se organizan los equipos en empresas que intentan estar a la vanguardia en la gestión de equipos y el desarrollo de software. Además Pablo nos da muchísimo contenido útil para todos aquello interesados en las metodologías ágiles, si te interesa conocer más sobre ésta manera de desarrollar software no puedes perderte éste episodio. Si al escuchar el podcast os surge alguna duda podéis usar los comentarios para exponerla y Pablo estará encantado de resolverla. EN ÉSTE EPISODIO APRENDERÁS: Qué son las metodología ágiles y que cambio implican respecto al desarrollo de software tradicional Cómo se organizan los equipos en empresas punteras de software Cuáles son las mayores dificultades al implementar las metodologías ágiles Cómo mejorar el flujo de trabajo de los equipos. Cuáles son los referentes en metodologías ágiles en la actualidad Puedes escucharlo aquí. LINKS Y RECURSOS DE LOS QUE HABLAMOS EN EL EPISODIO: (INCLUYE BIBLIOGRAFÍA RECOMENDADA POR PABLO DOMINGO) LEAN Y KANBAN Kanban: Successful Evolutionary Change for Your Technology Business de David J.Anderson Lean Software Development: An Agile Toolkit de Tom Poppendieck y Marie Poppendieck AGILE Agile Kaizen: Managing Continuous Improvement Far Beyond Retrospectives de Ángel Medenilla Management 3.0: Leading Agile Developers, Developing Agile Leaders de Jurgen Appelo Essential Scrum: A Practical Guide to the Most Popular Agile Process de Kenneth S. Rubin COACHING Co-Active Coaching: Changing Business, Transforming Lives de Henry Kimsey-House DESARROLLO DE SOFTWARE Agile Software Development, Principles, Patterns, and Practices de Robert C. Martín Refactoring: Improving the Design of Existing Code de Martín Fowler MOB PROGRAMMING http://mobprogramming.org/ An experience of its author PABLO DOMINGO @pavleras https://www.linkedin.com/pub/pablo-domingo/22/939/5b3 becomeagile.wordpress.com GRACIAS POR ESCUCHAR! Muchas gracias por unirte a Game Stuff y escuchar el episodio, si quieres dejar feedback estaré encantado de responderte en la sección de comentarios de más abajo. Además si te ha gustado el episodio sería increíble si lo compartieras en redes sociales mediante los botones del lateral de la página. También puede dejar una reseña en Itunes y me ayudarás a llegar a más personas y seguir generando contenido de utilidad para la comunidad. Puedes suscribirte al podcast en Itunes o en Ivoox para recibir automáticamente los nuevos podcast sin preocuparte de nada. No olvides que puedes seguirme en @danielgguillen o en Facebook! Y por último agradecer a @pavleras su asistencia al podcast, hasta la próxima!

This week we follow up on Apple Music issues, iTunes, the judicious use of shitty code with Design Stamina Hypothesis  and Apple's rumored Car. Greg and Aaron go on a couple of tangents on AI and the new Cross Point memory. Our Picks: Ghostery, open source Objective-C, ASCIIwwdc, Paint Code and Telekinesis (beta). Sponsored by: Hired.com Episode 50 Show Notes: Apple Music The Highs and Very Lows of Day 1 Usability I Got My Music Back. At Least Most Of It Hired.com/morethanjustcode Intel and Micron unveil 3D XPoint, a brand new memory technology Design Stamina Hypothesis Refactoring - Improving the Design of Existing Code Rumor: Apple’s Finder App to get Cocoa Rewrite for Snow Leopard Apple is reportedly considering teaming up with BMW to build an electric car Apple Car Development is Advancing In the Beginning Was the Command Line Intel and Micron unveil 3D XPoint, a brand new memory technology The AI Revolution: The Road to Superintelligence 360iDev 2015 Episode 50 Picks: Ghostery Objective-C Runtime source code ASCIIwwdc Paint Code and Telekinesis

03:42 - Derek Prior Introduction Twitter GitHub Blog thoughtbot @thoughtbot thoughtbot Code Review Guides The Bike Shed Podcast @_bikeshed 04:01 - Code Reviews Derek Prior: Implementing a Strong Code-Review Culture @ RailsConf 2015 Slides 05:14 - What happens when you don’t do code reviews? 06:30 - Not Emphasizing Code Quality, Setting Code Review Up for Failure Edge Cases Diverse Feedback, Team Conflict 10:43 - Code Reviewing Yourself: Answering Your Own Questions 12:03 - The Evolution of Code Review (Code Review as an Asynchronous Process) 14:51 - Small Changes, “Pull Request Bombs” Handling Architectural Disagreements and Discussions Improving the Design of Existing Code by Martin Fowler (with Kent Beck, John Brant, William Opdyke, and Don Roberts) 23:49 - Making Code Review a Supportive Process Stop Issuing Commands; Ask Probing Questions DON’T Use “Why didn’t you  ________?” DO Use “Have you considered _________?” or “That’s interesting…I might have used _______.” 30:32 - What qualities should reviewees have? 34:27 - Getting Code Reviews Introduced Into Company Culture 38:30 - Making Sure Code Reviews Get Done 40:47 - Tagging Specific Team Members LGTM = Looks Good To Me Gerrit 44:39 - Other Handy Code Review Tools Style Guides rubocop JSHint sass-lint Hound repo Code Climate 47:49 - Code Review Feedback Resources for Solo Programmers exercism.io pairprogramwith.me CodeNewbie Ruby Monday JavaScript Tuesday Python Thursday Picks Code Newbie Podcast: Sandi Metz Part I (Saron) Code Newbie Podcast: Sandi Metz Part II (Saron) If Google Were A Guy (Saron) LEGO Ideas - Lovelace & Babbage (Coraline) CoverMyMeds is offering Ruby on Rails training for experienced developers (David) CoverMyMeds Billboard 1 (David) CoverMyMeds Billboard 2 (David) The Bike Shed Podcast (Derek) The Ember RFC Process (Derek) tota11y (Derek) Eileen Uchitelle: How to Performance @ GoRuCo 2015 (Derek) Olympus SP-100EE (Avdi)

03:42 - Derek Prior Introduction Twitter GitHub Blog thoughtbot @thoughtbot thoughtbot Code Review Guides The Bike Shed Podcast @_bikeshed 04:01 - Code Reviews Derek Prior: Implementing a Strong Code-Review Culture @ RailsConf 2015 Slides 05:14 - What happens when you don’t do code reviews? 06:30 - Not Emphasizing Code Quality, Setting Code Review Up for Failure Edge Cases Diverse Feedback, Team Conflict 10:43 - Code Reviewing Yourself: Answering Your Own Questions 12:03 - The Evolution of Code Review (Code Review as an Asynchronous Process) 14:51 - Small Changes, “Pull Request Bombs” Handling Architectural Disagreements and Discussions Improving the Design of Existing Code by Martin Fowler (with Kent Beck, John Brant, William Opdyke, and Don Roberts) 23:49 - Making Code Review a Supportive Process Stop Issuing Commands; Ask Probing Questions DON’T Use “Why didn’t you  ________?” DO Use “Have you considered _________?” or “That’s interesting…I might have used _______.” 30:32 - What qualities should reviewees have? 34:27 - Getting Code Reviews Introduced Into Company Culture 38:30 - Making Sure Code Reviews Get Done 40:47 - Tagging Specific Team Members LGTM = Looks Good To Me Gerrit 44:39 - Other Handy Code Review Tools Style Guides rubocop JSHint sass-lint Hound repo Code Climate 47:49 - Code Review Feedback Resources for Solo Programmers exercism.io pairprogramwith.me CodeNewbie Ruby Monday JavaScript Tuesday Python Thursday Picks Code Newbie Podcast: Sandi Metz Part I (Saron) Code Newbie Podcast: Sandi Metz Part II (Saron) If Google Were A Guy (Saron) LEGO Ideas - Lovelace & Babbage (Coraline) CoverMyMeds is offering Ruby on Rails training for experienced developers (David) CoverMyMeds Billboard 1 (David) CoverMyMeds Billboard 2 (David) The Bike Shed Podcast (Derek) The Ember RFC Process (Derek) tota11y (Derek) Eileen Uchitelle: How to Performance @ GoRuCo 2015 (Derek) Olympus SP-100EE (Avdi)

03:42 - Derek Prior Introduction Twitter GitHub Blog thoughtbot @thoughtbot thoughtbot Code Review Guides The Bike Shed Podcast @_bikeshed 04:01 - Code Reviews Derek Prior: Implementing a Strong Code-Review Culture @ RailsConf 2015 Slides 05:14 - What happens when you don’t do code reviews? 06:30 - Not Emphasizing Code Quality, Setting Code Review Up for Failure Edge Cases Diverse Feedback, Team Conflict 10:43 - Code Reviewing Yourself: Answering Your Own Questions 12:03 - The Evolution of Code Review (Code Review as an Asynchronous Process) 14:51 - Small Changes, “Pull Request Bombs” Handling Architectural Disagreements and Discussions Improving the Design of Existing Code by Martin Fowler (with Kent Beck, John Brant, William Opdyke, and Don Roberts) 23:49 - Making Code Review a Supportive Process Stop Issuing Commands; Ask Probing Questions DON’T Use “Why didn’t you  ________?” DO Use “Have you considered _________?” or “That’s interesting…I might have used _______.” 30:32 - What qualities should reviewees have? 34:27 - Getting Code Reviews Introduced Into Company Culture 38:30 - Making Sure Code Reviews Get Done 40:47 - Tagging Specific Team Members LGTM = Looks Good To Me Gerrit 44:39 - Other Handy Code Review Tools Style Guides rubocop JSHint sass-lint Hound repo Code Climate 47:49 - Code Review Feedback Resources for Solo Programmers exercism.io pairprogramwith.me CodeNewbie Ruby Monday JavaScript Tuesday Python Thursday Picks Code Newbie Podcast: Sandi Metz Part I (Saron) Code Newbie Podcast: Sandi Metz Part II (Saron) If Google Were A Guy (Saron) LEGO Ideas - Lovelace & Babbage (Coraline) CoverMyMeds is offering Ruby on Rails training for experienced developers (David) CoverMyMeds Billboard 1 (David) CoverMyMeds Billboard 2 (David) The Bike Shed Podcast (Derek) The Ember RFC Process (Derek) tota11y (Derek) Eileen Uchitelle: How to Performance @ GoRuCo 2015 (Derek) Olympus SP-100EE (Avdi)

Support the shows at devchat.tv/kickstarter!   01:45 - Michele Titolo Introduction Twitter Blog Reddit Women Who Code Ruby Rogues Episode #147: APIs That Don't Suck with Michele Titolo 02:26 - Deconstructing and Decoupling Reuse Goals 08:36 - Having Seams in Your Code to Avoid Conflict 8 Patterns to Help You Destroy Massive View Controller 11:35 - The Deconstructing Mindset (Finding Reuse Patterns) The Rule of Three Inheritance 17:48 - The Decorator Pattern 18:43 - Categories 21:34 - Sharing UI (User Interface) Codes 23:55 - Mechanics of Sharing Code Between Apps Jeffrey Jackson: Private Cocoapods CocoaPods Guide: Podspec Syntax Reference 29:02 - Lessons Learned: Easy Ways/Patterns to Know When to Break Up Small Functionalities Separate as Soon As Possible Do a Local Pod Using the Path Option (Path is Your Friend!) CocoaPods Guide: Private Pods Have a Good Code Review Process 33:23 - Cocoapods: Commit to Source or Not? 39:59 - Team Collaboration Spotify [YouTube] Kent Beck: Software G Forces: The Effects of Acceleration Picks Refactoring: Improving the Design of Existing Code by Martin Fowler (Pete) Working Effectively with Legacy Code by Michael Feathers (Pete) Refactoring To Patterns by Joshua Kerievsky (Pete) WWDC 2010 Session 138: API Design for Cocoa and Cocoa Touch (Andrew) [Slides] Michele Titolo: Cocoa Design Patterns in Swift (Andrew) The Cocotron (Andrew) Matt Gallagher: Design of a multi-platform app using The Cocotron (Andrew) Zombie Monkie by Tallgrass Brewing Company (Jaim) Getting out and participating in programming language communities (Chuck) The Earthsea Cycle Series Book Series by Ursula K. Le Guin (Chuck) The Pixar Touch by David A. Price (Chuck) 8 Patterns to Help You Destroy Massive View Controller (Michele) Artsy - iOS at Scale - objc.io issue #22 (Michele)

Support the shows at devchat.tv/kickstarter!   01:45 - Michele Titolo Introduction Twitter Blog Reddit Women Who Code Ruby Rogues Episode #147: APIs That Don't Suck with Michele Titolo 02:26 - Deconstructing and Decoupling Reuse Goals 08:36 - Having Seams in Your Code to Avoid Conflict 8 Patterns to Help You Destroy Massive View Controller 11:35 - The Deconstructing Mindset (Finding Reuse Patterns) The Rule of Three Inheritance 17:48 - The Decorator Pattern 18:43 - Categories 21:34 - Sharing UI (User Interface) Codes 23:55 - Mechanics of Sharing Code Between Apps Jeffrey Jackson: Private Cocoapods CocoaPods Guide: Podspec Syntax Reference 29:02 - Lessons Learned: Easy Ways/Patterns to Know When to Break Up Small Functionalities Separate as Soon As Possible Do a Local Pod Using the Path Option (Path is Your Friend!) CocoaPods Guide: Private Pods Have a Good Code Review Process 33:23 - Cocoapods: Commit to Source or Not? 39:59 - Team Collaboration Spotify [YouTube] Kent Beck: Software G Forces: The Effects of Acceleration Picks Refactoring: Improving the Design of Existing Code by Martin Fowler (Pete) Working Effectively with Legacy Code by Michael Feathers (Pete) Refactoring To Patterns by Joshua Kerievsky (Pete) WWDC 2010 Session 138: API Design for Cocoa and Cocoa Touch (Andrew) [Slides] Michele Titolo: Cocoa Design Patterns in Swift (Andrew) The Cocotron (Andrew) Matt Gallagher: Design of a multi-platform app using The Cocotron (Andrew) Zombie Monkie by Tallgrass Brewing Company (Jaim) Getting out and participating in programming language communities (Chuck) The Earthsea Cycle Series Book Series by Ursula K. Le Guin (Chuck) The Pixar Touch by David A. Price (Chuck) 8 Patterns to Help You Destroy Massive View Controller (Michele) Artsy - iOS at Scale - objc.io issue #22 (Michele)

In podcast 19 of the Niche Pursuits Podcast, I was able to sit down with Elaine Heney and discuss her business of building mobile phone applications.  She has currently built over 200 iPhone or Android Apps and only started about a year ago! I was completely amazed at the success she is having, and knew I had to have her on the show. Elaine has an interesting story because she's not a programmer and was just tired of working for someone else (sound familiar?).  After creating her first app, she saw a little bit of success...not much, but enough to keep her intrigued by the app market.  As a result, she did something that I could never do...she quit her job before she was really making much money! She decided that she was going to give herself a few months to do nothing but work on her iPhone app business...and well, it turns out that it worked big time! She has now built over 200 mobile phone applications and is comfortably living off this full-time business.  She share tips on building iPhone apps and more on her blog at: TheChocolateLabApps.com.

Ben Orenstein is joined by David Heinemeier Hansson, the creator of Ruby on Rails and a partner at 37signals. David and Ben discuss David's normal day, his working relationship with Jason Fried, how their blog, Signal vs. Noise, is important to the company, how he got into programming, where he draws his inspiration from, some good books he's read and how he learns today, how he overcomes fear and why he takes risks, how he got into racing, why he enjoys it, what he learns from it, and how feedback loops and goal posts help you learn, inspire you, and help you know how good you are. They then go on to explore what David would, or wouldn't, change about Rails, and how he sees Rails evolving into the future. David also talks a little bit about the new product 37signals has in development, and 37signals' overall product strategy, coding at 37signals and his approach to providing guidance to the team, what role he plays on Rails core, what he cares about, and what he pays attention to, and much, much more. David's website Signal vs. Noise Domain-Driven Design: Tackling Complexity in the Heart of Software Patterns of Enterprise Application Architecture Refactoring: Improving the Design of Existing Code Extreme Programming Explained: Embrace Change Smalltalk Best Practice Patterns Code Complete: A Practical Handbook of Software Construction David Heinemeier Hansson's racing Sinatra Node.js Follow @thoughtbot, @dhh, and @r00k on twitter.

Enregistré le 8 février 2011 Hudson vs Jenkins http://java.net/projects/hudson/ http://jenkins-ci.org/ Bamboo - http://www.atlassian.com/software/bamboo/ CloudBees - http://www.cloudbees.com/ InfraDNA - http://infradna.com/ DEV@Cloud - http://www.cloudbees.com/dev.cb RUN@Cloud - http://www.cloudbees.com/run.cb Kenai - http://kenai.com/ Software Freedom Conservancy - http://sfconservancy.org/ Sonatype - http://www.sonatype.com/ http://www.sonatype.com/people/2011/02/hudsons-bright-future/ http://jenkins-ci.org/content/hudsons-future http://kohsuke.org/bye-bye-hudson-hello-jenkins/ http://nighthacks.org/roller/jag/entry/hudson_is_dead_long_live http://jenkins-ci.org/content/jenkins http://sacha.labourey.com/2011/01/31/hudson-is-now-jenkins/ http://www.sonatype.com/people/2011/02/hudsons-bright-future/ http://lacostej.blogspot.com/2011/02/sonatypes-hudsons-bright-future-answer.html http://prezi.com/4googejf66it/bordeaux-jug-lightning-talk-jenkins/ Twiki http://twiki.org/ FOSWIKI http://foswiki.org/  SouJava dans le JCP http://blogs.sun.com/theaquarium/entry/soujava_proposed_by_oracle_for http://blogs.oracle.com/henrik/2011/01/oracle_nominates_bruno_souza_of_soujava_to_jcp_ec.html http://blogs.sun.com/pcurran/entry/jugs_and_the_jcp Java EE 7 JPA 2.1 http://jcp.org/en/jsr/detail?id=338 JAX-RS 2.0 - http://jcp.org/en/jsr/detail?id=339 Restlet - http://www.restlet.org/ Servlet 3.1 EJB 3.2 EL 3.0 Tomcat 7 http://tomcat.apache.org/tomcat-7.0-doc/index.html http://tomcat.apache.org/security-6.html http://tomcat.apache.org/security-7.html JBoss AS 6.0 http://community.jboss.org/blogs/donnamishelly/2011/01/04/jboss-application-server-6-goes-final http://blog.softwhere.org/archives/1050 Google Google CEO change  http://www.readwriteweb.com/archives/google_ceo_eric_schmidt_steps_down_larry_page_take.php http://techcrunch.com/2011/01/20/google-ceo-change/ Google I/O http://techcrunch.com/2011/02/07/google-io-tickets-sell-out-in-59-minutes/   Amazon Elastic Beanstalk http://nighthacks.org/roller/jag/entry/elastic_beanstalk http://aws.amazon.com/elasticbeanstalk/ JBoss SteamCannon - http://steamcannon.org/ Google App Engine - http://code.google.com/appengine/ Blog SteamCannon vs Beanstalk - http://steamcannon.org/news/2011/01/19/steamcannon-vs-elastic-beanstalk/ Les departs de Sun un an apres http://pelegri.wordpress.com/2011/01/02/a-year-after-the-people/ http://blogs.sun.com/sandoz/entry/301_moved_permanently L'outil de la semaine Perf4J http://perf4j.codehaus.org/ JUGs et conferences ParisJUG 3 ans - http://www.parisjug.org/xwiki/bin/view/Meeting/20110228 WhatsNextParis - http://whatsnextparis.com/ Mix-IT - http://www.mix-it.fr GeekAndPoke http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0147e2645a4f970b-pi XKCD http://xkcd.org/ TED http://www.ted.com/ Livres Groupe les cast codeurs - http://groups.google.com/group/lescastcodeurs CleanCode Effective Java Refactoring : Improving the Design of Existing Code de Martin Fowler et Kent Beck entre autres Test Driven : TDD and Acceptance TDD for Java Developers de Lasse Koskela Java Concurrency in Practice Java performance tuning Filthy Rich clients, de Romain Guy et Chet Haase (Swing) ALGORITHMIQUE APPLICATIONS EN C de Jean Marie Lery (debat pour ou contre les questions d'algorithmie en interview) Thinking in Java http://www.mindview.net/Books/TIJ/ RESTful Web Services The Pragmatic Programmer: From Journeyman to Master Nous contacter Contactez-nous via twitter http://twitter.com/lescastcodeurs sur le groupe Google http://groups.google.com/group/lescastcodeurs ou sur le site web http://lescastcodeurs.com/ Flattr-ez nous sur http://lescastcodeurs.com/

Writing Code is the Easy Part is the new slogan for the website. It basically boils down to the fact that putting up syntacticly correct code is the simplest part of coding. More difficult is solving problems and all of the other things that come with having a job or working for clients. Here are some of the things that I listed as the harder parts of coding: Legacy Code Readability Testability Best Practices Writing Tests Team Dynamics Customer Communication Translating Behavior into Code Data Integrity Security Maintainability Systems Integration Server Technologies Databases Finding a Job Hiring and Firing Working on Boring stuff Job Fulfillment Here are affiliate links to some of the books that I mentioned: Refactoring: Improving the Design of Existing Code Design Patterns: Elements of Reusable Object-Oriented Software Code Complete: A Practical Handbook of Software Construction The Pragmatic Programmer: From Journeyman to Master The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) Here are the links to the podcast episodes by: Chad Fowler (Part 1, Part 2) Dave Thomas (Part 1, Part 2) Finally, I would really appreciate a $5 donation to help me get to RubyConf. Download this Episode