{"id":13395327,"url":"https://github.com/timoxley/best-practices","last_synced_at":"2026-02-25T07:40:01.721Z","repository":{"id":2097730,"uuid":"3038538","full_name":"timoxley/best-practices","owner":"timoxley","description":"Tidbits of developer best practices from around the web","archived":false,"fork":false,"pushed_at":"2023-01-04T14:18:03.000Z","size":79,"stargazers_count":1280,"open_issues_count":9,"forks_count":282,"subscribers_count":81,"default_branch":"master","last_synced_at":"2025-10-13T18:54:03.831Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/timoxley.png","metadata":{"files":{"readme":"README.es.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2011-12-23T05:21:37.000Z","updated_at":"2025-10-06T09:13:23.000Z","dependencies_parsed_at":"2023-01-11T16:07:51.560Z","dependency_job_id":null,"html_url":"https://github.com/timoxley/best-practices","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/timoxley/best-practices","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/timoxley%2Fbest-practices","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/timoxley%2Fbest-practices/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/timoxley%2Fbest-practices/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/timoxley%2Fbest-practices/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/timoxley","download_url":"https://codeload.github.com/timoxley/best-practices/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/timoxley%2Fbest-practices/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29814135,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-25T05:36:42.804Z","status":"ssl_error","status_checked_at":"2026-02-25T05:36:31.934Z","response_time":61,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-30T17:01:52.575Z","updated_at":"2026-02-25T07:40:01.685Z","avatar_url":"https://github.com/timoxley.png","language":null,"funding_links":[],"categories":["Others","Best Practice ##","others"],"sub_categories":["Version 1.x ###"],"readme":"# Mejores Pr\u0026aacute;cticas de la Programaci\u0026oacute;n - Tidbits\n### Una colecci\u0026oacute;n de citas y frases obtenidos de la web para programadores\n\nUtilice su propio juicio en su aplicaci\u0026oacute;n.\n\n* * *\n\n## Nunca construyas aplicaciones grandes\n\nEl secreto para construir aplicaciones grandes es nunca construir aplicaciones grandes. Divide tus aplicaciones en piezas m\u0026aacute;s peque\u0026ntilde;as. Entonces, ensambla esas piezas del tama\u0026ntilde;o de un mordizco que pueden ponerse a prueba, dentro de tu aplicaci\u0026oacute;n grande.\n\n*Justin Meyer, autor de JavaScriptMVC*.\n\n[Fuente](http://bitovi.com/blog/2010/11/organizing-a-jquery-application.html).\n\n## La calidad importa\n\nCuando escucho \"¡S\u0026Oacute;LO LIBERA DE UNA VEZ EL C\u0026Oacute;DIGO QUE YA FUNCIONA!\" pienso en todas las aplicaciones que dej\u0026eacute; de usar porque gradualmente perdieron la habilidad de iterar.\n\n*Avdi Grimm*\n\n[Fuente](https://twitter.com/#!/avdi/status/180747721852985344).\n\n## No escribas c\u0026oacute;digo\n\nNo escribas c\u0026oacute;digo (escribe nuevo c\u0026oacute;digo solamente cuando todo lo dem\u0026aacute;s falle) es la lecci\u0026oacute;n m\u0026aacute;s importante que todo desarrollador deber\u0026iacute;a aprender. La cantidad de c\u0026oacute;digo duplicado y basura que existe (en todos los proyectos) es abrumadora. En muchos casos los desarrolladores ni se molestan en echar un vistazo. Lo \u0026uacute;nico que quieren es escribir c\u0026oacute;digo.\n\n[Fuente](http://blogs.agilefaqs.com/2009/10/19/biggest-stinkers)\n\n#### Reducir la cantidad de c\u0026oacute;digo en tu producto deber\u0026iacute;a ser una meta\n\n\"Odio el c\u0026oacute;digo, y quiero tan poco c\u0026oacute;digo como sea posible en nuestro producto.\"\n\n*Jack Diederich*\n\n[Fuente](http://pyvideo.org/video/880/stop-writing-classes)\n\n#### Mant\u0026eacute;n las dependencias al m\u0026iacute;nimo\n\nEl viejo dicho \"No reinventes la rueda\" no aplica cuando la rueda es del motor de una locomotora.\n\n[Fuente](http://www.reddit.com/r/programming/comments/1bcebh/programming_best_practices/c9616mn)\n\n## Deja de escribir clases\n\nLa se\u0026ntilde;al de que \"esto no deber\u0026iacute;a ser una clase\" es cuando la clase tiene dos m\u0026eacute;todos, y uno de ellos es el constructor. Cuando quiera que veas estas se\u0026ntilde;ales, significa que probablemente deber\u0026iacute;as haber escrito s\u0026oacute;lo una funci\u0026oacute;n.\n\n*Jack Diederich*\n\n[Fuente](http://pyvideo.org/video/880/stop-writing-classes)\n\n## Olvida nuevas funcionalidades, simplemente haz lo mismo pero mejor\n\nEl problema: es muy f\u0026aacute;cil perder de vista lo que m\u0026aacute;s importa a los usuarios, que es el rendimiento y la usabilidad de las aplicaciones y las funcionalidades que usan m\u0026aacute;s a menudo.\n\n*Tim Anderson*\n\n[Fuente](http://www.itjoblog.co.uk/2011/06/making-better-software.html)\n\n## Reinventa la rueda\n\nInventar tus propias ruedas te da un mayor aprecio y entendimiento de c\u0026oacute;mo funcionan las ruedas y qu\u0026eacute; hace que una sea buena.\n\n[Fuente](http://nodejs.debuggable.com/2011-02-26.txt)\n\n## No hagas cosas dif\u0026iacute;ciles, haz cosas sencillas\n\n* Simple es mejor que complejo.\n* Complejo es mejor que complicado.\n* Plano es mejor que anidado.\n* La legibilidad cuenta.\n* Si la implementaci\u0026oacute;n es dif\u0026iacute;cil de explicar, es una mala idea.\n* Si la implementaci\u0026oacute;n es f\u0026aacute;cil de explicar, puede que sea una buena idea.\n\n*El Zen de Python*\n\n[Fuente](http://www.python.org/dev/peps/pep-0020/)\n\n## Reescribir \u003e Refactorizar\n\nSi vas a cambiar m\u0026aacute;s del 25% de una clase o m\u0026eacute;todo, considera simplemente reescribirlo. Escribir\u0026aacute;s c\u0026oacute;digo m\u0026aacute;s limpio.\n\n## Refactorizar \u003e Reescribir\n\n#### Excusas comunes para reescribir software\n\n1. El c\u0026oacute;digo apesta\n2. \"Ahora somos mucho m\u0026aacute;s listos\"\n3. Escogimos la plataforma y/o lenguaje equivocado\n\n#### Por qu\u0026eacute; (casi) nunca es buena idea reescribir\n\n1. [Tardar\u0026aacute; m\u0026aacute;s de lo que piensas](http://en.wikipedia.org/wiki/Hofstadter's_law)\n2. Los mercados cambian\n2. Los clientes existentes se frustran\n3. Puedes limpiar el c\u0026oacute;digo refactorizando\n4. No controlas la reescritura, ella te controla a ti\n\n[Fuente](http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx)\n\n## Acepta que no tienes idea de c\u0026oacute;mo esto va a crecer\n\nLa clave es reconocer desde el principio que no tienes idea de c\u0026oacute;mo esto va a crecer. Cuando aceptes que no lo sabes todo, empezar\u0026aacute;s a dise\u0026ntilde;ar el sistema defensivamente... Deber\u0026iacute;as invertir la mayor parte de tu tiempo en pensando en interfaces en vez de implementaciones.\n\n*Nicholas Zakas, autor de \"High-performance JavaScript websites\"*\n\n[Fuente](http://radar.oreilly.com/2011/06/big-javascript-apps-teams.html)\n\n[Reconocimiento a Addy Osmani](http://addyosmani.com/largescalejavascript/)\n\n## Evita c\u0026oacute;digo que apesta\n\n[Fuente](http://www.codinghorror.com/blog/2006/05/code-smells.html)  \n\n[Fuente](http://web.archive.org/web/20120130234037/http://stackoverflow.com/questions/114342/what-are-code-smells-what-is-the-best-way-to-correct-them)\n\n## Escribe pruebas unitarias\n\nTodo programador sabe que deber\u0026iacute;a escribir tests para su c\u0026oacute;digo. Pocos lo hacen. La respuesta universal al \"¿Por qu\u0026eacute; no?\" es \"Tengo mucha prisa.\" R\u0026aacute;pidamente esto se convierte en un c\u0026iacute;rculo vicioso. Cuanta m\u0026aacute;s presi\u0026oacute;n sientas, menos pruebas escribir\u0026aacute;s. Entre menos pruebas escribas, ser\u0026aacute;s menos productivo y tu c\u0026oacute;digo se volver\u0026aacute; menos estable. Entre menos productivo seas, mayor presi\u0026oacute;n sentir\u0026aacute;s. Los programadores se desgastan con esos ciclos. Romperlos requiere de una influencia externa. Encontramos esa influencia externa en un simple framework de pruebas que nos deja hacer peque\u0026ntilde;as pruebas que hacen una gran diferencia.\n\n[Fuente](http://junit.sourceforge.net/doc/testinfected/testing.htm)\n\n#### [Sin las pruebas unitarias] no est\u0026aacute;s refactorizando, s\u0026oacute;lo est\u0026aacute;s cambiando porquer\u0026iacute;a. — Hamlet D'Arcy\n\n## Para escribir pruebas unitarias efectivas, debes escribir c\u0026oacute;digo que se pueda probar\n\n### Falla #1: El constructor hace trabajo real\n#### Se\u0026ntilde;ales de alerta\n\n* Existe `new` en un constructor o en la declaraci\u0026oacute;n de un atributo.\n* Static method calls in a constructor or at field declaration\n* Se hace algo m\u0026aacute;s que solo asignar en los constructores.\n* El objeto no esta completamente inicializado cuando el constructor termina (cuidado con los m\u0026eacute;todos 'para inicializar')\n* Control de flujo en un constructor (existe un condicional o un bucle)\n* Code does complex object graph construction inside a constructor rather than using a factory or builder\n* Adding or using an initialization block\n\n### Falla #2: Digging into Collaborators\n#### Se\u0026ntilde;ales de alerta\n\n* Objects are passed in but never used directly (only used to get access to other objects)\n* Law of Demeter violation: method call chain walks an object graph with more than one dot (.)\n* Suspicious names: context, environment, principal, container, or manager\n\n### Falla #3: Brittle Global State \u0026 Singletons\n#### Se\u0026ntilde;ales de alerta\n\n* Adding or using singletons\n* Adding or using static fields or static methods\n* Adding or using static initialization blocks\n* Adding or using registries\n* Adding or using service locators\n\n###Falla #4: La clase hace demasiado\n#### Se\u0026ntilde;ales de alerta\n\n* Al resumir lo que hace la clase se incluye el conector \"y\".\n* La clase ser\u0026iacute;a dif\u0026iacute;cil de leer y captar para nuevos miembros del equipo.\n* La clase tiene atributos que son utilizados s\u0026oacute;lo en algunos m\u0026eacute;todos.\n* La clase tiene m\u0026eacute;todos est\u0026aacute;ticos que s\u0026oacute;lo operan sobre p\u0026aacute;rametros\n\n[Fuente](http://misko.hevery.com/code-reviewers-guide/)\n\n[Fuente](http://misko.hevery.com/presentations/)\n\n## Desarrollo guiado por pruebas con Inversi\u0026oacute;n de Control\n\nIncluso si no est\u0026aacute;s probando tu c\u0026oacute;digo, deber\u0026iacute;as escribir c\u0026oacute;digo que pueda probarse. IoC permite c\u0026oacute;digo \"testeable\". Inyecta dependencias que faciliten las pruebas o \"mocks\" al tiempo de probar a fin de aislar la unidad bajo prueba.\n\n## Evita mezclar la creaci\u0026oacute;n de objetos con la l\u0026oacute;gica de aplicaci\u0026oacute;n\n\n[Fuente](http://misko.hevery.com/2008/09/30/2008/07/08/how-to-think-about-the-new-operator/)\n\n## Evita crear deuda t\u0026eacute;cnica\n\n\"Aunque el c\u0026oacute;digo inmaduro funcione bien y sea totalmente aceptable al cliente, cantidades excesivas del mismo har\u0026aacute;n que un programa sea indomable, conduciendo a programadores extremadamente especializados y, finalmente, a un producto inflexible. [...] Un poco de deuda acelera el desarrollo siempre y cuando se pague prontamente con una reescritura. [...] *Cada minuto que se gasta en c\u0026oacute;digo no muy bien escrito cuenta como inter\u0026eacute;s en esa [deuda](http://en.wikipedia.org/wiki/Technical_debt)*. Organizaciones enteras de ingenier\u0026iacute;a pueden detenerse bajo la deuda de implementaci\u0026oacute;n sin consolidar\"\n(Cursivas m\u0026iacute;as)\n\n[Fuente](http://c2.com/doc/oopsla92.html)\n\n## La optimizaci\u0026oacute;n prematura es la ra\u0026iacute;z de todos los males\n\n\"Los programadores desperdician mucha cantidad de tiempo pensando o preocup\u0026aacute;ndose sobre el rendimiento de partes del programa que no son cr\u0026iacute;ticas y estos intentos realmente tienen un poderoso impacto negativo cuando consideramos el mantenimiento y la depuraci\u0026oacute;n. Deber\u0026iacute;amos olvidarnos de las pequenas optimizaciones, digamos el 97% del tiempo: la optimizaci\u0026oacute;n prematura es la ra\u0026iacute;z de todos los males\"\n\n[Fuente](http://c2.com/cgi/wiki?PrematureOptimization)\n\n## Planifica, Planifica, Planifica\n\nEs mucho m\u0026aacute;s barato hacerlo correctamente la primera vez que rehacerlo posteriormente. Mientras m\u0026aacute;s pronto se identifica y soluciona un problema, es m\u0026aacute;s barato hacerlo.\n\n\"El general que gana una batalla hace muchos c\u0026aacute;lculos en su templo antes del fragor la batalla. \u2028\u2028El general que pierde una batalla hace pocos c\u0026aacute;lculos con antelaci\u0026oacute;n. Hacer muchos c\u0026aacute;lculos lleva a la victoria y pocos c\u0026aacute;lculos a la derrota: ¡cu\u0026aacute;nto m\u0026aacute;s ning\u0026uacute;n c\u0026aacute;lculo en absoluto! Por dar atenci\u0026oacute;n a este punto yo puedo preveer quien es probable que gane o pierda\"\n\n#### \"Los planes son in\u0026uacute;tiles, pero la planificaci\u0026oacute;n lo es todo\" - Sir Winston Churchill\n\nFor this to work, everyone involved has to listen, everyone has to be open, everyone has to be responsive. Or we could keep flailing away with the fucked up attitude that “it has to be this way” because the sacred project plan says it’s this way. Because that really is a lot of fun, isn’t it?\n\n## Programar tambi\u0026eacute;n envuelve ense\u0026ntilde;ar a tu equipo\n\n... un equipo de programadores mediocres, sin experiencia que trabajan juntos y escriben para el beneficio del equipo tiene la capacidad de convertirse en un gran equipo, y pueden tomar este enfoque para crear otros grandes equipos. *Todo se resume en si el eqiupo ve su trabajo como s\u0026oacute;lo escribir c\u0026oacute;digo, o escribir con el objetivo de tanto codificar como aprender*\"\n(Cursivas m\u0026iacute;as)\n\n*Reginald Braithwaite*\n\n[Fuente](http://www.theserverside.com/tt/articles/article.tss?l=ProgrammingisAlsoTeachingYourTeam)\n\n### \"El elemento m\u0026aacute;s importante del desarrollo de software con \u0026eacute;xito es aprender\"\n\nCuando todo el equipo alcanza un cierto nivel de competencia, existe una superficie expuesta de aprendizaje muy grande y el equipo es capaz de absorber m\u0026aacute;s informaci\u0026oacute;n.\n\n[Fuente](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html)\n\n## \"...hay mentiras, mentiras descaradas, y estimaciones de desarrollo de software\"\n\nSoftware can only partially be designed in advance. ... requirements suffer from observation, that the act of building software causes the requirements to change. ...technical factors cannot be perfectly understood, that only the act of trying to build something with specific components will reveal all of the gotchas and who-knews associated with a chosen technology strategy. ...software design is an iterative process, starting with a best guess that is continually refined with experience.\nthe normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls.\n\n[Fuente](http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html)\n\nNobody likes to look stupid. If you’re a professional and someone puts you on the spot to answer “how long will this take?” it’s only human to want to provide an answer. Whether you call it professional pride or ego, it’s a powerful driver.\nGood IT workers really don’t like saying “I don’t know.” If they say it, they probably mean it. So stop pushing for a definitive answer when one doesn’t exist.It’s perfectly reasonable to want some sort of plan up front. I’m actually one of those funny types who believe up front planning is a necessity. So long as everyone understands an estimate is just that: an estimate. You learn as you go along and discover more detail. So you revise the estimate accordingly.\n\n[![The mess we're in](https://cloud.githubusercontent.com/assets/43438/4344401/0ddd5fc8-408f-11e4-8887-b0bfbce91dc7.png)](https://www.youtube.com/watch?v=lKXe3HUG2l4)\n\n*Joe Armstrong, autor de Erlang*\n\n##Your architecture should resemble your domain\n\nSo what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: health care system, or accounting system, or inventory management system? Or do they scream: rails, or spring/hibernate, or asp?\n\nLa arquitectura no deber\u0026iacute;a ser dada por el framework. Los frameworks son herramientas para utilizarlas, no arquitecturas a las que haya que conformarse. Si tu arquitectua est\u0026aacute; basada en frameworks, entonces no puede estar basado en tus casos de uso.\n\n*Uncle Bob Martin, \"Screaming Architecture\"*\n\n[Fuente](http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html)\n\n## Sigue los principios de X\n\n* No a\u0026ntilde;adir nueva funcionalidad a menos que un desarrollador no pueda completar una aplicaci\u0026oacute;n real sin ella.\n* Es tan importante decidir qué no es parte del sistema, como decidir que s\u0026iacute; lo es. No respondas a las necesidades de todo el mundo; en lugar de eso, haz el sistema extensible para que las necesidades adicionales puedan cubrirse de una manera compatible ascendente.\n* La \u0026uacute;nica cosa peor que generalizar a partir de un ejemplo, es generalizar a partir de ning\u0026uacute;n ejemplo.\n* Si un problema no es comprendido completamente, probablemente es mejor no proporcionar ninguna soluci\u0026oacute;n.\n* Si puedes conseguir el 90 por ciento del efecto deseado para el 10 por ciento del trabajo, utiliza la soluci\u0026oacute;n m\u0026aacute;s simple.\n* A\u0026iacute;sla la complejidad tanto como sea posible.\n* Proporcionen un mecanismo en vez de una pol\u0026iacute;tica. En particular, pongan la interfaz de pol\u0026iacute;tica en las manos de los clientes.\n\n[Fuente](http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Design_principles)\n\n## Sigue los principios de Unix\n\n\"Esta es la filosof\u0026iacute;a de Unix: escribe programas que hagan una sola cosa y la hagan bien. Escribe programas para trabajar colectivamente. Escribe programas para manejar flujos de texto, porque esta es una interfaz universal.\"\n\n*Doug McIlroy, citado en \"A Quarter Century of Unix\" [Salus]. Addison-Wesley. 1994. ISBN 0-201-54777-5.*\n\n* Regla de Modularidad: Escribe partes simples conectadas por interfaces limpias.\n* Regla de Claridad: La claridad es mejor que la habilidad y el ingenio.\n* Regla de Composici\u0026oacute;n: Diseña programas para ser conectados a otros programas.\n* Regla de Separaci\u0026oacute;n: Separa la pol\u0026iacute;tica del mecanismo; separa las interfaces de los motores.\n* Regla de Simplicidad: Diseña pensando en la simplicidad; agrega complejidad solamente donde debas.\n* Regla de Parsimon\u0026iacute;a: Escribe un programa grande solamente cuando es claro por demostraci\u0026oacute;n que ninguna otra cosa funcionar\u0026aacute;.\n* Regla de Transparencia: Diseña pensando en la visibilidad para hacer la inspecci\u0026oacute;n y la depuraci\u0026oacute;n m\u0026aacute;s f\u0026aacute;cil.\n* Regla de Robustez: La robustez es la hija de la transparencia y la simplicidad.\n* Regla de Representaci\u0026oacute;n: Pliega el conocimiento dentro de los datos de tal manera que la l\u0026oacute;gica del programa pueda ser estúpida y robusta.\n* Regla de la M\u0026iacute;nima Sorpresa: En el diseño de interfaces, siempre has la cosa menos sorprendente.\n* Regla del Silencio: Cuando un programa no tiene nada sorprendente que decir, no deber\u0026iacute;a decir nada.\n* Regla de Reparaci\u0026oacute;n: Cuando debas fallar, falla ruidosamente y tan pronto como sea posible.\n* Regla de Econom\u0026iacute;a: El tiempo del programador es costoso; consérvalo en preferencia al tiempo de m\u0026aacute;quina.\n* Regla de Generaci\u0026oacute;n: Evita el hackeo manual; escribe programas para escribir programas cuando puedas.\n* Regla de Optimizaci\u0026oacute;n: Haz prototipos antes de pulir. Haz que funcione antes que lo optimices.\n* Regla de Diversidad: Desconf\u0026iacute;a de todas las pretensiones para \"una v\u0026iacute;a verdadera\".\n* Regla de Extensibilidad: Diseña para el futuro, porque estar\u0026aacute; aqu\u0026iacute; m\u0026aacute;s pronto de lo que piensas.\n\n*Eric S. Raymond, \"The Art of Unix Programming\"*\n\n[Fuente](http://www.catb.org/esr/writings/taoup/html/ch01s06.html)\n\n[![Bitdeli Badge](https://d2weczhvl823v0.cloudfront.net/timoxley/best-practices/trend.png)](https://bitdeli.com/free \"Bitdeli Badge\")\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftimoxley%2Fbest-practices","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftimoxley%2Fbest-practices","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftimoxley%2Fbest-practices/lists"}