Shinka
-
Posts
5 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Events
Articles
Downloads
Store
Posts posted by Shinka
-
-
Thanks for the reply and the counterpoints! I bounced around quite a bit to address some of the points I had a lot of feelings about, so sorry if it's a little stilted.
Maybe I'm not emphasizing the important of choosing good packages enough. If it's not one of the top three results when I google "<framework> <feature>" (e.g. "rails forums") and if I can't find half a dozen Medium articles about it (because apparently every dev has one of those now), then I'm probably not interested. But even then, there's no shortage of options.
Also, 200+ dependencies sounds horrifying and is absolutely not what I'm advocating for here.
QuoteHonestly, I would never use a third party authentication system unless I did a really thorough deep dive on it.
At least in the Rails community, it's a cardinal sin to roll your own auth—and this is coming from a framework that does half the work of authentication for you via bycrpt and has_secure_password. Devise has thousands of man hours behind it and a large community of developers and users alike who have vetted the system more thoroughly than I could vet something custom. And if a new security vulnerability does come up, it'll be patched before you can even file an issue on GitHub. This is an article that I think explains the trade-offs well, specifically the "The Pros and Cons of Using a Gem like Devise" section.
Devise can get complicated if you want to customize it in a way that isn't built into the configs—but then you have gems like Sorcery that are more barebones but still have the benefit of hundreds of man hours behind them.
QuoteIt's really easy to pick something that looks pretty but is a resource hog or has really crappy security issues. I have seen the projects in code canyon that look pretty but have scripts with really horrible XSS and SQL injection prone code. I even know of a popular one that would let people upload any file and could delete your whole database or dump it into a downloadable .zip archive.
I would almost never use a closed-source package, which is what it looks like Code Canyon mostly provides. (Forgive me if I'm wrong!) If an open source package has a dozen contributors and hundreds of thousands of downloads, then I feel pretty safe in assuming that it's secure. Open source devs aren't shy with their criticism.
Of course, extremely popular packages can still have some kind of vulnerability—but writing your own code doesn't mean it's going to be free of security issues, either. And the same goes for performance concerns, etc.
But a markdown parser? That's going to be two classes and a couple dozen lines of code, if that. There's not much room to introduce security vulnerabilities—though performance could still be a concern if it uses a metric ton of regex. Then I'd pop into the issues, read a couple articles, and if no one's complained, It's probably solid!
QuoteTake your forums example, having to modify the forums to use your own users table can be time consuming and if not done correctly can easily open huge security flaws.
Both forum solutions I linked to assume you're using Laravel's standard auth (and thus a Users model), but they also provide convenient ways to change that if you're not. Thredded (the best regarded forum package for Rails) assumes you're using a Devise or Devise-like User model, but it looks like you just need to change ~3 lines of code to use a different model.
If you're using a quality package, hooking it up with your existing structure should be a cinch. I should have worded the "event hooks" part of my first post better—I look for packages that are easily extensible and configurable.
(Tying into what I said earlier, a search for "rails forum gem" has Thredded, Forem, and Discourse as its top three results. Forem is unmaintained, but that's evident both by the bold text in the readme section as well as the date of its last commit.)
QuoteSomething that's well tested, updated frequently (or completely unit tested and stable) and mature can be a good candidate for a third party package.
Thank you for putting this succinctly. This is the only kind of package I'm suggesting should be leveraged. Don't just grab random snippets from Codepen or GitHub and assume they're safe.
QuoteAlso, you end up with a lot of extra functionality you don't want and will never use.
This is a really good point—if a package has a dozen major features that you know you're never going to use, maybe it's not the one for you. I've steered a few people away from using full-fledged forum software like MyBB because it's way too much for what they need.
That said, definitely do consider what features you want now for your MVP vs what you might want to add in the future.
-
@Boltgreywing I totally respect your disagreement, but I'd like to address a few of your counterpoints! (: (I came back up here after writing the entire post, and I'm sorry it turned out so long! I got wildly out of control somewhere part way through and couldn't stop myself.)
QuoteForums I have to disagree with you on that. Forums are really simple to design. The default behaviour of forums is they automatically send messages to user's inboxes and automatically subscribe users to topics that they don't want. This is bad behaviour and spams the user's mailbox to no end. Private messages are simplistic to design and don't require much code. If you want a two tier message system then you are out of luck because most only work on the one tier system.
Out of the five or so forum packages I've researched, none of them send email notifications out of the box, though this would be very easy to implement on your end with event listeners. Email notification is a behavior that's very prevalent in full forum software—things like MyBB, Xenforo, IPB, and so on—and while I don't explicitly recommend integrating your project with most of those (they tend to have complex admin panels and a lot of features that are ultimately unnecessary when the forum is only a secondary feature) it's extremely simple to turn off email notifications. I just took a look into my Xenforo admin panel, and it looks like I could do so by flipping two or three switches.
Beyond that, forums are simple, at their most basic. But that's still time spent implementing, testing, and future regression testing; which means it's time not spent on your project's core (i.e. most important) features.
I imagine that most virtual pet sims would want the following features:
- Weighted categories, weighted forums, threads, and posts, and their respective validations
- Nested forms for threads and posts
- BBCode or Markdown parsing
- Notifications
- Permissions
- Pinning, locking, and deleting threads
- Permissions
- Soft deletion
I wrote a very long breakdown of each feature, what would go into implementing them, and time estimates for each; but it was stupidly long so I ripped it out. If you're interested, ping me and I can throw it up somewhere.
TL;DR I estimate implementing the above features would take me ~12.5 hours, including testing; versus finding and plugging in a forum package would take me ~3 hours, including time spent adding in post vistas and user titles. The custom solution estimate is not including front end work—things like general design, AJAX paging or posting, and mobile responsiveness—which offhandedly I might estimate at another 12 hours, depending on design and JavaScript experience. The package solution estimate is assuming it comes with an elegant enough front end. (Out of the packages I mentioned, Chatter has a lovely front end, but Laravel Forum's is extremely basic and would require additional design work.)
(Maybe I'll time myself later and see how long it takes me to whip up a solution with those features. Hmm.)
When your developers are also working full time jobs, your budget is small or nonexistent, and you're trying to get out an MVP asap, 12 hours (we can even bump it down to 8, to be conservative; again, not including front end work) is a lot of time. Or maybe it's not for you—then implement a custom solution to your heart's desire!
Now imagine you have a dev who gets halfway through implementing this and then bails. The next developer has to get up to speed with the already existing code, which might not be particularly difficult but is still additional time.
That said, if you already have a solution for a particular feature that works and does what you need it to do, it's probably not worth ripping it out and replacing it with a package! But if you have a page of eventual improvements you want to make, maybe take a step back and reevaluate.
I am probably also 100% biased because I'm sick of writing forum solutions and fixing other peoples' forum solutions.
But I'm currently hooking a site up with Flarum, which is a little different than what I've been recommending because Flarum is an entirely separate app that's outside of the main project, and I had to integrate its authentication with the main project's. Still, to write a custom solution as beautiful, seamless, and responsive as Flarum would take me a metric ton of time.
Anyway that is certainly enough of me ranting about forums.
QuotePrivate messages are simplistic to design and don't require much code. If you want a two tier message system then you are out of luck because most only work on the one tier system.
A basic PM system is simple. But my basic argument stands: it takes time and maintenance, and time is at a premium for small moonlighting teams. If you want to get into things like live/realtime updates, that's trickier. You could do write an AJAX solution, but that can be expensive depending on your request interval; but for proper realtime, you probably need to learn or brush up on sockets, which is time spent getting up to speed, implementing the solution, and then testing it.
I'm not sure what you mean by two tier, so I can't comment on that!
QuoteUser verification systems are a bit more complex depending on what you are doing. I set mine up from scratch. If you like to see the code for that you can pm me.
I appreciate the offer, but I've setup a couple before. (: When I'm learning a new web framework, I like to roll my own user authentication and authorization workflow because it touches on a little bit of everything. (Though I would never use any of these auth solutions on a live site!) My bias also comes into play here because if I never have to deal with Rails' mailer again, I can die happy.
QuoteAudits I am not using at this moment.
I haven't used auditing before, but activity logs and model changelogs have been pretty vital for my workflow. (Not to mention for support on a live site! Restoring lost items is a cinch when you can see exactly where they were lost.)
QuoteSo most of things from this list I was able to create with relative ease. Meaning most of things I mentioned don't require plugins.
Gonna skip the rest of your points because most of them boil down to the above. Just because something is easy doesn't mean it's worth the time and maintenance. I've implemented 90% of the features I listed about, as a learning experience or otherwise, and most of them are easy. Most only require one or two models and tables, basic CRUD actions, etc. But it's still reinventing the wheel! If you need a very customized or unusual solution, then that's different. Code away!
QuoteAlso Bootstrap is a load of bs do not use it unless you want your entire file screwed up!
I very much disagree, but I respect that Bootstrap is not your cup of tea. I'm assuming you're talking about the HTML/CSS framework and not like, bootstrappers. Bootstrap can be a very powerful tool for teams that don't have a lot of design experience. (Back end devs are universally terrible at design, but give me something that I can use as building blocks, and I'm good to go!) Bootstrap's mobile friendly solution is eventually going to be superfluous as flexbox and css-grid pick up traction; but for now, there might not be enough browser support for those to be viable alternatives. The last software company I worked at spent a significant sum of money (a number that about made me swoon) for a UI framework and a few screens for the most important pages—and it was built off of Bootstrap 3!
Bootstrap-based designs can look rather samey. I can usually pick out what sites are using Bootstrap, but with a little bit of custom styling, you have something decent looking for way less work than it would take to build from the ground-up.
When I'm prototyping a hobby project, I almost always use Bootstrap, though I've taken a couple other CSS frameworks for a spin.
QuoteMy advice: Code the sections that make sense to code for and those that are difficult use plugins for. This will keep your sections relatively lean.
I'll qualify my philosophy of "Code as little as possible" with "... as long as the time spent plugging in a good package and adding in necessary features is less than the time it would take to write it yourself." If there are only a couple half-baked private message packages for your given framework, then absolutely write your own! Or if you want a "threaded" system (like how Reddit's comments work, where replies are nested), don't bludgeon an ill-fitting package into the right shape! Don't settle for something that isn't almost exactly what you need but understand the amount of effort it would take to add extra features vs start from the ground up. (Adding in post vistas? Easy. Adding a threaded post system? Probably more work than it's worth.)
This is way too long of a post, and I'm sorry if I sound like a broken record. No one philosophy is going to fit everyone's needs, but this is mine and it has served me well. (:
-
Update 12/7/2017: This diatribe is intended for developers using frameworks like Laravel, Rails, Symfony, etc.
TL;DR See list at end of post for features that probably aren't worth the effort to write yourself
Introduction
When starting a new project, there's a temptation to write everything yourself, from user registration to forums. Don't. You don't need to reinvent the wheel when there are already hundreds of implementations out there. Every hour you spend developing a common feature is an hour you are not developing the core of your game, e.g. breeding or pet customization; and every line of code you write is another line you need to maintain. When you have a fresh, clean slate in front of you, maintenance doesn't seem like a huge concern, but the time cost quickly adds up.
TL;DR Make "Code as little as (reasonably) possible" your driving philosophy
"But..."
"... I just need a lightweight forum system."
The lightest traditional forum system requires at least three database tables (forums, threads, posts) and associated models, each with their own set of validations (threads must have subjects, posts cannot be empty, etc). Then you need authorization guards so only staff can create and delete categories, pin and lock threads, and so on. This might not sound like a lot of work for someone who can spin all that up in four commands (looking at you, Rails devs), but remember that for every feature, that's another thing you need to write tests for and QA. (You are writing tests, right?)
TL;DR There's a package for that.
"... I need X special feature."
Let's say you want to display a user's title on their posts. This isn't a feature that's going to come in a third party forum package, but it's a feature that can easily be added to one. Good third party packages have interfaces or designs that allow you to tweak or hook into their behavior. For that forum package I've convinced you to use, just open up the post view and add in the relevant property. This is (potentially) one line of forum-related code.
TL;DR There's not a package for that, but there's a package you can build off of.
Choosing the Right Package
Caveats
- Only use popular open source software with a permissive license e.g. MIT, CC0, or Unlicense. Most major open source projects use one of these licenses, or some other flavor of Unlicense. If a package's license is not mentioned in their readme section, there's likely a LICENSE file at the root of the repository.
- Never trust closed source software that isn't extremely well regarded—and even then, I can't think of any examples beyond maybe plugins for game engines like Unity, which is a different beast entirely.
Metrics
When choosing a package, there are four qualities I look at first:
- Features
- Extensibility
- Contributors, downloads, and community regard
- Stability and ongoing maintenance
TL;DR You want a package that reasonably fits your use case, is easily extensible or configurable, is highly regarded by your framework's community, has a robust stable release or is actively updated, and doesn't have any major bugs!
(Wait, that TL;DR might have been longer than the section...)
Regard, Downloads, & Community Standards
You don't want to just grab any random package from GitHub's dregs. The number of contributing developers and downloads isn't the end-all metric for package evaluation, but if a package has a dozen contributors and hundreds of thousands of downloads, it's probably good to go.
If there's not a package in the top three results when you google "<framework> <feature>" (e.g. "rails forums") and if you can't find half a dozen Medium articles about it (because apparently every dev has one of those now!), then you might be out of luck on that one.
Features
Let's continue with the forum example and pretend you're using PHP and Laravel for your back-end. Write down bullet points for all the features you need. An example might be
- Traditional forum structure, e.g. categories > forums > threads > posts
- Permissions, e.g. only staff can pin or lock threads
- Admin panel to create/edit/delete categories and forums
- @mentions
Now let's do a quick search for "laravel forum package", and it looks like there are two strong contenders, Laravel Forum and Chatter. Now let's see how they compare to our desired feature list:
- Laravel Forum uses a traditional forum structure, but Chatter takes a cue from Flarum's tag-based structure
- Both have a permissions system using Laravel's authorization
- Both have admin panels
- Neither has @mentions
You absolutely need @mentions, so both of those are deal breakers. But wait! There's a package for that!
Another quick search for "laravel mentions" brings up Laravel Mentions. (Do you sense a naming theme here?) Laravel Mentions allows you to set any text input or textarea as capable of @mentions, which is even better than if it was baked right into the forums! This allows you to reuse the same package for @mentions in both the forums and, for example, user profile comments!
On the other hand, if you really do just need a lightweight forum solution and every available package has dozens of features you never intend to use (and that aren't written modularly so they can't be removed), then write your own! You want to weigh features you need against features a package has that you need and that you don't need.
TL;DR Look for packages that reasonably fits your use case, but decouple features where possible (e.g. separating forums and @mentions)
Extensibility
Eventually, you might want to add notifications for things like receiving PMs, a subscribed thread getting updated, and news/announcements. This is best done via events and event listeners or some other kind of Observer pattern, where every notifying action dispatches an event, e.g. sending a PM dispatches PMSentEvent. Both Laravel Forum and Chatter dispatch events, so we're good to go there!
An ideal third party package is easily extensible and configurable—maybe using traits, interfaces, or method hooks! But even easily extensible packages are useless if they don't document how you can extend them.
TL;DR Look for packages that are extensible and have comprehensive documentation
Stability & Ongoing Maintenance
Assuming you're looking at a GitHub repository, click that Commits tab and note the frequency of commits and the dates of the latest commits. If there hasn't been a commit in over a year, that package might not be maintained, and it might not be patched if you encounter a major issue. This doesn't have to be a deal breaker—if the package has had a robust release cycle, is on a stable version, and doesn't appear to have many bugs, then it's probably safe to use.
Now click the Issues tab to be taken to the repository's issues tracker. Take a look at the first page of issues. Are they tagged or marked by contributors, e.g. as "solved" or "not an issue"? Do most of them seem to be due to user error, e.g. migration errors? Then you're good to go! But if the top issue has three pages of users all reporting the same major issue, it's probably best to pass that one by.
TL;DR Look for packages that actively maintained or have a stable release without any significant issues
The Big List of Stuff You Shouldn't Write Yourself
And example Laravel packages!
- Authentication (you should almost never write your own authentication! but Laravel 5 comes with its own auth system anyway)
- Forums (if you didn't get that already)
- Private messages
- Instant messages
- @mentions
- Tags
- Audits, model changelogs, and logging
- Authorization (Laravel devs are lucky enough to have that included in the core framework via guards)
- User verification (that register -> receive email -> verify registration workflow)
- Invite/Beta codes
- Friendship systems
- Online/recently online users
- Caching
-
2
-
1
-
Update 12/05/2017
Due to the volume of requests, I am now handling my volunteer work as a feature queue! I will complete one feature for a given project before bouncing it to the back of the queue. Paid work will take priority.
Paid Work
PM me to hash out details for paid work. I will try to offer rates appropriate for your budget, and I prefer to be paid per feature than per hour. Paid work takes priority over queued volunteer work.
Prerequisites, Conditions, & Miscellaneous
- I will not work on a project that does not have version control and a remote repository, e.g. GitHub or BitBucket. If you do not already have version control set up, it is extremely simple to do so. See @owlmanatt's tutorial or Github - Set Up Git for a short guide.
- I am probably not the person you want to build your project from the ground up! I promise no long-term commitment to any project I volunteer for (unless paid), and this kind of work is better done by a developer who will remain on the project for the foreseeable future. I may be willing to do so but only if the project has a solid foundation—things like artwork and design documents.
- If the feature you're looking to develop is "common" (i.e. private message systems, forums, authentication), it is almost always better to use an open source third-party package. If you're not sure how to find a package that suits your needs, ping me and I can guide you to the right resources.
- Tying into the above, I will not write user authentication systems (i.e. registration/login/logout). The potential for security vulnerabilities is too great for me to take responsibility for that risk, and you almost never want to roll your own authentication anyway. There is undoubtedly a third-party package you can use instead, which has the benefit of being vetted and tested by a large community.
________________________________________
Looking For...
A virtual pet site or sim with passionate people behind it. I'm a professional software dev with time to kill and an itch for code. If you need someone to whip up a prototype, fill in where another developer left off, or even develop new features for just a little bit of praise and attention
and beer, I'm your gal.Experience
Currently working as a web developer on both front-end and back-end, in ReactJS and Java respectively. In my spare time, I write open source extensions for MyBB and Xenforo. I also occasionally take requests from roleplaying communities, which range from tutorials, to code snippets, to full-fledged extensions. A few of my recent projects are:
Languages & Frameworks
Ruby (on Rails), PHP (with limited Laravel experience), Java, Python, C#, JavaScript, JQuery, ReactJS, Angular, HTML, Bootstrap, Sass
- Most of my back-end web dev experience is in Rails and PHP
- I am not a designer, but I am very familiar and comfortable with HTML, CSS, and CSS preprocessors like Sass, as well as modern web standards and mobile responsiveness
- I can learn new languages and frameworks if necessary
Availability
I work a standard 9am-5pm job, so my availability is strictly after 5pm EST on week days. My weekends are largely open to scheduling.
Contact
Reply to this thread or shoot me a PM to get the ball rolling.
Coding As Little As Possible - Third party packages and when to use them
in Tutorials and Guides
Posted · Edited by Shinka
I've worked on several large projects (all of which used either Angular or React) and none got close to that high! But your experience is different than mine.
I'm absolutely not assuming that. I was using Rails as an example and to make my point more clearly; I'm sorry if I did not convey that well enough. Every major web framework has a community standard auth package or has auth as a core feature (Laravel and Django, off the top of my head). If you're not using a web framework, then you're not the intended audience for my spiel, considering the major differences in plugging in a package between a framework and a vanilla language (e.g. Laravel vs vanilla PHP). I'll tack this onto the top of my original post.
My experience is extremely different than yours, but you do you. For me at least, frameworks have greatly improved my workflow and efficiency, and I would never willingly write a web app in a vanilla language.
Which is why I am only suggesting open source software, the vast majority of which uses the MIT license. Every package I've discussed or linked to uses MIT—except for Talk, which uses the even more permissive CC0 license. I don't know the last time I saw a major package that wasn't either of those or some other flavor of Unlicense.
(For reference, MIT and CC0 both allow private use, commercial use, distribution, and modification.)
This has been precisely my point, so I suspect we're just talking past each other. (:
I explained earlier in this post that my perspective is not as a Rails developer (though Rails is my favorite web framework; Laravel is a close contender). The same applies for every other framework, front end or back end. Why write your own Angular pagination when you can grab a community gold standard package that does it better? Unless you need something very specific to your use case, in which case... don't! Like I've said before, devs need to weigh the time and maintenance cost of writing a custom solution vs adapting a quality package.
Which is why I explained in my last post how I made that point poorly and how extensibility in general is an important metric. (: