3 ms·

Pardon my shameless plug, but I've been working on something for a looong time that combines all of the above into one massive time-saving system. The hardest

by tfb 13y ago

Pardon my shameless plug, but I've been working on something for a looong time that combines all of the above into one massive time-saving system. The hardest part is definitely making it fast and efficient while also being user friendly. If you take a look at the trends of the web over the past decade, I really think this (or something like it) is the future of web application development. Long story short, you can (mostly) point-and-click to build flexible/reusable JS widgets that can either be laid out on a single page or embedded elsewhere. (Side note: I developed a system on top of jQuery similar to backbone that should eventually allow the widgets' HTML to be cached and loaded instantly, as opposed to regenerating each widget's components from its JSON representation every time. This is where "Server-side HTML vs. JS Widgets vs. Single-Page Web Apps" all come together.) I've already posted a description in a comment before, so I apologize if you've happened to have already read it. Here's a more detailed description: It was originally designed to appeal to non-programmers; and I would have released it months ago but decided to rewrite nearly everything to make the code as modular/flexible/easy-to-learn as possible for developers (both newbie and seasoned). Before I link to it, I'd like to apologize for overly generic descriptions currently on the site. I whipped together the entire site in a few days not knowing the exact direction I wanted to take the software, so I left everything pretty vague; I really just wanted some content that at least somewhat described my ideas. I'll put the link at the bottom of this comment so you read all this first. From a technical standpoint, this is currently where I'm at with it: - Users create a myriad of widgets that can "interact" with each other; the fullscreen version of Loggur consists of "layouts" of widgets, while the mobile version of Loggur lets you access widgets individually in typical mobile app fashion - Databases are incredibly easy to create; just add fields to a widget and specify their relationships to one another - All kinds of special extensions included by default, like automatic importing of various data sources, scraping of websites, cron jobs, PDF report generation, emails, sms notifications, triggers, and graphing - Everything is taggable for reuse, from the apps themselves to widgets to components to elements to lists and to the data associated with all of the above; you can either "mirror" or "clone" any one of these parts in another app/widget/component by doing a quick search for tags (or if you know the exact path to the part, just enter that); so for example, if you really liked what someone else has made and wanted to reuse parts of it in your own app, you'd do a quick search for it, clone it, and modify it to suit your needs, saving a lot of time - Data associated with apps can be any combination of public/private, singular (your individual profile), and/or group-specific; you can quickly/immediately switch between views of each - Permissions on everything; specify who can view and/or edit apps, widgets, components, elements, lists, and/or data - Appearances are somewhat customizeable and will become much more so at some point; customization currently consists of the basics like colors, backgrounds, and sizes; apps are designed to be scalable to any screen resolution (think large dashboards ;) - Each one of the pieces outlined above (widgets, components, etc.) can be embedded on your own site(s) through small snippets of code - Data associated with apps is easily accessible, currently only available in JSON but if for some reason other formats are requested in high numbers, I might do that - Users can toggle the ability to view app/data updates as they happen in realtime; they can also invite each other (or a Loggur dev if they need help) to take turns using/building an app - Regarding the mention above about rewriting the project to be more modular/flexible for developers, I felt doing this was 100% necessary/worth it because it occurred to me a few months ago that the best approach to make this succeed in the long term is to make this a legitimate platform (buzzword, sorry!) where developers can quickly/easily make and share awesome extensions and be rewarded (paid) for their work Check it out (sign up for it ;) here and remember to ignore the bad, vague descriptions currently on the site: http://loggur.com http://loggur.com

TeeWEE 13y ago
"I would have released it months ago but decided to rewrite nearly everything" Recipy for disaster. Release early, release often. Is this b.t.w. a one-man project? Big code bases written by one man which doesn't get out to the public early is a risky undertaking. However I really admire your passion/enthousiasm.
- tfb 13y ago
  Yeah it's just me for now. There would be too much overhead involved in getting anyone else up to speed on it and getting them on the same wavelength. I have a fair amount of documentation, so when I everything is finished that I personally have to do, bringing in others won't be an issue then as it would be now. I beg to differ about your claim that delaying its release by a few months is a recipe for disaster. If you saw what I had written prior to the rewrite... that was a recipe for disaster. First impressions are huge. And this project isn't your typical easy come, easy go type of startup. There's a lot to it, and if one piece of the puzzle is missing, it stands no chance in the real world, so it has to be done right from the very beginning. I do have a list of things that would be okay to do after its initial release, of course. I have plenty of runway time, so the reality of it is that releasing it months ago instead of months from now would not have been beneficial at all. If anything, I'd have gotten discouraged because of complaints of massive amounts of bugs and complaints about lack of features/functionality, and I'd have ended up rushing to write code and it would be ugly. But since I have plenty of runway to spare, I can do it right and release everything (mostly) as advertised, save a few gray hairs, and maybe even have better timing on its release. Timing is everything. And if you asked me a year ago, I would have said the world is not yet ready for Loggur. I'm noticing a trend on HN that quite a few people seem to think there's one path to take for a successful startup. Repeating the "release early, release often" mantra is evidence of this fact. Yes, that mindset might work for the majority of startups, but certainly not all of them.
- Chris2048 13y ago
  Waiting until it's done can make first-impressions better, and iron out potential bad-decisions that might then have to be supported. ReRo can become a mantra sometimes.

by tfb 13y ago

TeeWEE 13y ago

"I would have released it months ago but decided to rewrite nearly everything" Recipy for disaster. Release early, release often. Is this b.t.w. a one-man project? Big code bases written by one man which doesn't get out to the public early is a risky undertaking. However I really admire your passion/enthousiasm.

tfb 13y ago
Yeah it's just me for now. There would be too much overhead involved in getting anyone else up to speed on it and getting them on the same wavelength. I have a fair amount of documentation, so when I everything is finished that I personally have to do, bringing in others won't be an issue then as it would be now. I beg to differ about your claim that delaying its release by a few months is a recipe for disaster. If you saw what I had written prior to the rewrite... that was a recipe for disaster. First impressions are huge. And this project isn't your typical easy come, easy go type of startup. There's a lot to it, and if one piece of the puzzle is missing, it stands no chance in the real world, so it has to be done right from the very beginning. I do have a list of things that would be okay to do after its initial release, of course. I have plenty of runway time, so the reality of it is that releasing it months ago instead of months from now would not have been beneficial at all. If anything, I'd have gotten discouraged because of complaints of massive amounts of bugs and complaints about lack of features/functionality, and I'd have ended up rushing to write code and it would be ugly. But since I have plenty of runway to spare, I can do it right and release everything (mostly) as advertised, save a few gray hairs, and maybe even have better timing on its release. Timing is everything. And if you asked me a year ago, I would have said the world is not yet ready for Loggur. I'm noticing a trend on HN that quite a few people seem to think there's one path to take for a successful startup. Repeating the "release early, release often" mantra is evidence of this fact. Yes, that mindset might work for the majority of startups, but certainly not all of them.
Chris2048 13y ago
Waiting until it's done can make first-impressions better, and iron out potential bad-decisions that might then have to be supported. ReRo can become a mantra sometimes.