Jump to content

Aho

Member
  • Posts

    84
  • Joined

  • Last visited

Awards

This user doesn't have any awards

Profile Information

  • Gender
    Male
  • Location
    The Interwebz

System

  • CPU
    Intel i7-4770k @ 4.7GHz
  • Motherboard
    ASUS Maximus VI Extreme
  • RAM
    Kingston 32GBs @ 2400MHz (11-11-11-31)
  • GPU
    (2) ASUS GTX Titans in SLI
  • Case
    Corsair 900D
  • Storage
    ASUS RAIDR PCI-E SSD, (2) OCZ Vertex 4 (128GB) SSDs, (2) 3TB Hitachi HDDs, Samsung 840 PRO 256GB SSD, (2) PNY 480GB SSDs
  • PSU
    Corsair AX1200i
  • Display(s)
    (2) ASUS VG248QE, PA279Q
  • Cooling
    GPUs cooled by (2) 480mm radiators, CPU cooled by 240mm and 120mm radiators
  • Keyboard
    Logitech G502 Proteus Core
  • Mouse
    Das Keyboard Model S Ultimate (Cherry MX Blue switches)
  • Sound
    ASUS Xonar Essence STX, Bose Companion 5 USB Speakers
  • Operating System
    Windows 10 Pro, OS X 10.11 (El Capitan, Hackintosh)
  1. Did you enable this option? chrome://flags/#disable-webgl
  2. Probably not, although I'm guessing it's certainly a more lucrative field. I would argue that most of the WordPress sites on the internet don't actually need to run such a powerful web app. Businesses use WP because it's easy to get up and running; you can sign up for a $5 web host, get a free domain, and easily deploy a WP instance in a few button clicks. The problem with that is, it doesn't scale (it won't handle an influx of users, and it will get become more expensive, as you mentioned, if they decide to move to their own servers) and it's unnecessary. Most of these WP sites don't actually have any dynamic content that can't be emulated by a static site generator like Jekyll. So unless a client needs a feature that absolutely can't be accomplished without an application like WP, go with Jekyll. You'll be saving yourself a few headaches in the long run (not having to maintain a full-blown application) and your clients will spend less money to be able to reach more people. They'll be able to throw the site up onto AWS S3, cache it with CloudFront, and not worry about security issues or (for any random reason) a sudden spur of traffic. As for content management by your clients, if you're really dedicated to this, spend some time building an administrative interface for the site. Features like a WYSIWYG editor that translates to Markdown. There are open-source projects that accomplish this, which you'll find by searching something like "jekyll admin" on Google. Take a look at this, I personally haven't used any of them though.
  3. I understand that benchmarks are almost everything to people, but you have to come back to the real world every now and then. http://www.phonearena.com/news/In-depth-test-of-the-iPhone-6-Galaxy-S6-HTC-One-M9-and-Nexus-6-settles-which-is-the-fastest_id68480 http://bgr.com/2015/04/22/galaxy-s6-vs-iphone-6-performance-tests-gaming/ The point to take away is that those benchmarks don't translate into any meaningful difference in actual performance.
  4. iOS devices with PowerVR GPUs consistently have some of the best graphics performance on the market, especially iPads.
  5. If you're looking to access, say, an SMB share remotely, setup a VPN server. Any other solution would be very insecure. Otherwise, you could setup something like ownCloud (https://owncloud.org/), a piece of open source software, and (run it with a reverse proxy like nginx and) expose the web server's port on your router.
  6. You can easily change the page title by finding the title element and modifying the text between it. var changeTitleText = function(newText){ var titleNode = document.getElementsByTagName('title')[0]; titleNode.innerHTML = newText;} To change when a user inputs text, just listen to the 'input' event on the text box or textarea: inputNode.addEventListener('input', function(){ changeTitleText(this.value);} For title changes based on the number of emails (and updating it when a new email has been received), you'll need to either have a method in your API's endpoint that quickly returns whether or not a user has new/unread emails and the number of new/unread emails and periodically send an AJAX request to check, or poll the server using a feature like WebSockets (not recommended just for this, though).
  7. Once you get OpenKM setup, which according to the quick install page should be quite simple, users should be able to connect directly to your server's IP address with the port on which the app is bound. In this case, it seems the default port is 8080, so users should be able to visit server.public.ip.here:8080 and access the site. Generally, servers shouldn't, by default, block access to these ports, but in case the ports are blocked, you will need to allow them to receive external traffic. I also wouldn't recommend allowing users to connect directly to the app server or making users connect directly to the server's IP with the app's port. Get a domain and use a reverse proxy. Nginx is easy to setup and a very fast web server that can be used a reverse proxy.
  8. Nor is it possible with most phones being released these days. The number of manufacturers that continue to support microSD slots and swappable batteries is small these days, with Samsung being the obvious elephant in the room.
  9. Are people taking into account that this is a tablet, not a phone? I can see potential issues arising if a single SIM system were implemented in a phone without any (universal) industry standards set in place, but on a tablet, it makes much more sense. Especially with the iPad, this is convenient for traveling (both domestically and internationally); it's not as if Apple is restricting the user's ability to choose a carrier...all carriers, except VZW, in the US that provided iPad service before, are still providing it with the Apple SIM. Plus, I don't think many of you realize that this is not some embedded chip; it's removable.
  10. C++ is not a good choice for a task such as this; however, I believe it can be accomplished using the libcurl library. A better alternative is to use a language like Perl, which has the powerful WWW::Mechanize module for web automation/interaction, Python, which has a library created based on WWW::Mechanize called mechanize, or Ruby, which has a gem called Mechanize that also accomplishes the same task.
  11. A simple way to do this is by adding a scroll event listener and changing the position of the element once the client scrolls past it. Essentially: - Get position of element relative to the page - Compare current scroll position to element's position - Set position property to fixed and top/left properties to 0 if the scroll position is >= the element position - Reset the position to its default if scroll position <= the element position Items 3 and 4 could be done without an if statement using CSS. You could also use a library such as Waypoints (jQuery plugin), but it's likely unnecessary for your uses.
  12. If you're going to customize the default elements within the framework, why not write them yourself? Overriding the default front-end framework classes will add to the file sizes of your stylesheets and increase loading time. The main reason I see people going towards Bootstrap or Foundation is for their responsive grid systems. It's certainly useful, being able to create a grid using such classes along the lines of "grid-50," but it's also unsemantic and unnecessary. There are much better tools out there for creating these grids; Singularity and Susy are the ones that stand out to me. They don't require that you include another library in your HTML and allow much more control over your design. I don't have anything against these frameworks, so I apologize if my posts sound incredibly snobby. I just advocate against using them. You will become a much better web designer by creating your own set of reusable design elements.
  13. Why in the world do you "need" 3GBs of RAM on a phone?
  14. I would stay away from Bootstrap and just about all other front-end frameworks, at least for now. Generally, they're bloated with crap you will never use and restrict your design choices. Take a little while longer with HTML and CSS; understand how a browser takes the markup, renders it, and applies styling. HTML5 elements such as <article> and <section> are frequently misused, so take some time to make sure you understand and can create semantic markup. It's important to SEO and the organization of your page's content. CSS can also get more complicated with many features from the new CSS3 standards that allow for more creation of interactive content that was previously done using JavaScript. I would take some time to learn those, as well. I would also suggest taking a look at SASS in combination with Compass after you feel comfortable with CSS. It's a "preprocesser" for CSS that adds many programming-like features to stylesheets. One of the most important problems it solves is DRY (don't repeat yourself), which is highly prevalent in plain CSS. For example, if you have multiple elements on a page that should be red, instead of defining "background: #FF0000;", you could define a variable "$some_elements_color: #FF0000;" and use "background: $some_elements_color;". This dramatically increases the maintainability of your stylesheets, especially when they get even bigger. SASS also contains mixins (essentially functions you define to output some CSS) so you could easily define a media query mixin such as: @mixin mq($min, $max){ @if $max == null { @media only screen and (min-width: $min) { @content; } } @[member=ElsePants] if $min == null { @media only screen and (max-width: $max) { @content; } } @[member=ElsePants] { @media only screen and (min-width: $min) and (max-width: $max) { @content; } }} and call "@include mq(some_min_width or null, some_max_width or null) { // properties }" every time you needed a media query instead of using the long standard way. There are even actual functions in SASS that can take input and return some output. SASS, coupled with Compass, will save your life as a web UI designer/developer. As you can see, there is a lot to learn in HTML and CSS and I don't believe 1-2 weeks is truly enough to grasp it all. Regarding the PHP/SQL/Rails concern...it really depends on what you want to build. PHP or Rails, coupled with SQL (some sort of RDB), will allow you to create web applications that generate the HTML front-end with dynamic content. For example, if you wanted to create a forum such as this, you would need a language like PHP or framework like Rails. PHP is a server-side language and Rails is a server-side framework built with Ruby; you will need a web server to handle requests to these applications. Node.js is a platform built on Chrome's JS engine that allows you to build "real-time", asynchronous applications. Unlike traditional web apps built on a framework such as Rails, Node.js doesn't wait for an action to complete; it instead uses callback functions that are triggered when the action emits an "event." If the action was to find a record in a database, for example, it could emit an event "found" and pass the user record to the callback function for the "found" event or "notFound" and pass the error back to the callback function for the "notFound" event. Node's event loop and EventEmitter is extremely useful for an application like a chat box which has constantly changing content. If you're simply looking to design websites, just focus on HTML, CSS, and JavaScript. With JavaScript, look at some of the MVC front-end frameworks; Ember, Angular, Backbone, etc...those are what the industry seems to be moving towards. Of course, you should learn the language first before diving into any framework. Hopefully that gives you some insight into the web development world; it's definitely a fun place to be.
×