Craft and publish engaging content in an app built for creators.
NEW
Publish anywhere
Post on LinkedIn, Threads, & Mastodon at the same time, in one click.
Make it punchier 👊
Typefully
@typefully
We're launching a Command Bar today with great commands and features.
AI ideas and rewrites
Get suggestions, tweet ideas, and rewrites powered by AI.
Turn your tweets & threads into a social blog
Give your content new life with our beautiful, sharable pages. Make it go viral on other platforms too.
+14
Followers
Powerful analytics to grow faster
Easily track your engagement analytics to improve your content and grow faster.
Build in public
Share a recent learning with your followers.
Create engagement
Pose a thought-provoking question.
Never run out of ideas
Get prompts and ideas whenever you write - with examples of popular tweets.
@aaditsh
I think this thread hook could be improved.
@frankdilo
On it 🔥
Share drafts & leave comments
Write with your teammates and get feedback with comments.
NEW
Easlo
@heyeaslo
Reply with "Notion" to get early access to my new template.
Jaga
@kandros5591
Notion 🙏
DM Sent
Create giveaways with Auto-DMs
Send DMs automatically based on engagement with your tweets.
And much more:
Auto-Split Text in Posts
Thread Finisher
Tweet Numbering
Pin Drafts
Connect Multiple Accounts
Automatic Backups
Dark Mode
Keyboard Shortcuts
Creators love Typefully
170,000+ creators and teams chose Typefully to curate their Twitter presence.
Marc Köhlbrugge@marckohlbrugge
Tweeting more with @typefully these days.
🙈 Distraction-free
✍️ Write-only Twitter
🧵 Effortless threads
📈 Actionable metrics
I recommend giving it a shot.
Jurre Houtkamp@jurrehoutkamp
Typefully is fantastic and way too cheap for what you get.
We’ve tried many alternatives at @framer but nothing beats it. If you’re still tweeting from Twitter you’re wasting time.
DHH@dhh
This is my new go-to writing environment for Twitter threads.
They've built something wonderfully simple and distraction free with Typefully 😍
Santiago@svpino
For 24 months, I tried almost a dozen Twitter scheduling tools.
Then I found @typefully, and I've been using it for seven months straight.
When it comes down to the experience of scheduling and long-form content writing, Typefully is in a league of its own.
Luca Rossi ꩜@lucaronin
After trying literally all the major Twitter scheduling tools, I settled with @typefully.
Killer feature to me is the native image editor — unique and super useful 🙏
Visual Theory@visualtheory_
Really impressed by the way @typefully has simplified my Twitter writing + scheduling/publishing experience.
Beautiful user experience.
0 friction.
Simplicity is the ultimate sophistication.
Queue your content in seconds
Write, schedule and boost your tweets - with no need for extra apps.
Schedule with one click
Queue your post with a single click - or pick a time manually.
Pick the perfect time
Time each post to perfection with Typefully's performance analytics.
Boost your content
Retweet and plug your posts for automated engagement.
Start creating a content queue.
Write once, publish everywhere
We natively support multiple platforms, so that you can expand your reach easily.
Check the analytics that matter
Build your audience with insights that make sense.
Writing prompts & personalized post ideas
Break through writer's block with great ideas and suggestions.
Never run out of ideas
Enjoy daily prompts and ideas to inspire your writing.
Use AI for personalized suggestions
Get inspiration from ideas based on your own past tweets.
Flick through topics
Or skim through curated collections of trending tweets for each topic.
Write, edit, and track tweets together
Write and publish with your teammates and friends.
Share your drafts
Brainstorm and bounce ideas with your teammates.
NEW
@aaditsh
I think this thread hook could be improved.
@frankdilo
On it 🔥
Add comments
Get feedback from coworkers before you hit publish.
Read, Write, Publish
Read, WriteRead
Control user access
Decide who can view, edit, or publish your drafts.
Ya podemos tener una única metodología para modelar bases de datos indiferentemente del motor de base de datos que vayamos a usar.
¿Por qué seguimos con el mismo modelo propuesto por Edgar Codd en ~1970 para bases de datos relacionales?
Sigo viendo muchos programadores, profesionales, que modelan sus bases de datos siguiendo el mismo patrón, ya sea directa o indirectamente, y lo peor de todo es que lo hacen mal.
Normalizar una base de datos tiene seis formas normales con tres casos especiales intermedios.
Si bien es cierto que todos los casos no fueron propuestos por Edgar Codd las tres primeras formas normales y el lenguaje único propuesto por él, lenguaje que ahora conocemos como SQL sí.
Hoy tenemos motores de bases de datos que no responden a ese lenguaje de consulta llamado NoSQL, y que tampoco tienen implementado un sistema de tablas denominado relacional.
Tenemos bases de datos NoSQL que responden a través de API y que no requieren de un esquema definido.
Ahora sí empecemos abriendo con la siguiente pregunta:
¿Cuales son las estructuras de datos que usan las bases de datos?
Hago esta pregunta para empezar a establecer las bases de lo que quiero proponer como metodología única de diseño.
Los que hemos sido, y los que son ingenieros de datos sabemos que hay varios pero los usados por el 99% de los motores de bases de datos son:
B+ Tree | Heaps | Graph
Hash | ISAM
Y pueden haber combinaciones como por ejemplo DynamoDB de AWS que es de tipo Hash y B+ Tree.
Pero en general todas usan o un sistema de Índices o un sistema de Nodos y Bordes tipo árbol.
La siguiente pregunta es de las más trascendentales para esta nueva propuesta de metodología y es:
¿Qué motivo a Edgar Codd para redactar en ~1970 su paper:
A Relational Model of Data for Large Shared Data Banks
Muy contrario a lo que muchos piensan en el paper Edgar Codd menciona varias motivaciones ordenadas por importancia:
- Independencia de las aplicaciones
- Representación de los datos
- Aumento en el número de tipos de datos
- Inconsistencia de datos
- Redundancia y Consistencia
Cada una de las preocupaciones y propuestas de Edgar Codd ya están resueltas de manera intrínseca en los motores de bases de datos modernas, aún así seguimos usando su propuesta de normalización de bases datos para crear los modelos asociados a las aplicaciones.
Ahora si la propuesta que denomino:
Metodología de modelado de bases de datos por análisis entrópico.
Entropía: Mide el número de microestados compatibles con el macroestado de equilibrio; también se puede decir que mide el grado de organización del sistema.
Esa definición es la que se le da en física a la entropía la cual entro a explicarles por qué la he llamado así y la importancia que tiene en la propuesta de diseño único de bases de datos.
Pero primero aclaremos algo el CRUD:
En la metodología que propongo no existe ni UPDATE ni tampoco DELETE solo existe CREATE y READ
Y esto por algo muy importante, los siguientes dos elementos claves en mi propuesta:
El primer elemento clave son los patrones de acceso:
Estos definen como obtienes los datos de la base de datos el READ.
El segundo elemento clave son los patrones de escritura:
Estos definen como los datos entrán en relación con el resto dentro del modelo el CREATE.
Esto tiene unas implicaciones importantes, y es la secuencia ordenada de los datos, tanto por orden alfabético como orden cronológico, algo que si o si en esta metodología debes tener en cuenta a la hora de modelar.
Volvamos a la entropía: Microestados compatibles con el macroestado.
Cuando modelas una base de datos en su etapa inicial tienes control de todo lo que se va a representar y la compatibilidad de estos, es decir, la relación entre los diferentes patrones de acceso.
Y la segunda parte de entropía habla de medir el grado de organización del sistema.
Y esto esta más relacionado en mi propuesta con el sistema de pruebas, cuando aparece un nuevo patrón de acceso o patrón de escritura denominado microestado o nuevo estado.
Cuando diseñas una serie de mecanismos para probar el rendimiento y la escalabilidad de la base de datos según el modelo definido, un nuevo microestado o nuevo estado debe ser fácil de incorporar porque no puede de ninguna forma romper el macreoestado.
Indiferentemente del motor de base de datos se va a tener un núcleo o core, ya sea un nodo, o una tabla.
A partir de ahí se plasman todos los patrones de escritura. Los patrones de acceso en parte van directamente sobre ese núcleo, y parte van a ir a índices o espejos (vistas)
Esta metodología busca tener el menor número de tablas el ideal es una, o el menor número de arboles lo ideal uno que supla todas las necesidades actuales como futuras.
Aunque puedo listar una serie de posibles ventajas, me gustaría mencionar una desventaja importante.
A nivel de arquitectura de software hay un trade-off dado que esta propuesta de metodología entra en conflicto con la agilidad, dado que debes invertir un tiempo importante en la definición de todo lo que la metodología pide.
Mi propuesta tiene muchas más partes, más detalladas, pero estas las quiero ir validando a través de la maestría en ingeniería de software que empezaré el próximo año, puede que termine siendo un paper, o un libro.